The Functionality Design

11.10.1.Conceptos generales

La diferencia principal entre redes ATM y IP es que las primeras son orientadas a conexión, mientras que las segundas no. La característica de que IP no está orientado a conexión (connectionless), y por ende Internet, es requerida para escalabilidad y tolerancia a fallos. IP es asociado naturalmente a “datagrama” y “per hop” routing, y por su naturaleza no soporta circuitos virtuales. Internet está basada en la entrega de datagramas según el modelo “best-effort”. No hay garantía en la entrega de datagramas. Los datagramas pueden sufrir delay, jitter, ser manipulados (mangling) o incluso perdidos (dropped) en sus caminos hacia los destinos.

El modelo IntServ fue diseñado para proveer QoS a flujos individuales, o a una sesión individual en el caso de aplicaciones multicast. Se requiere de una sesión que requiera una garantía específica de QoS para iniciar un procedimiento de configuración usando RSVP. RSVP establece “soft states” en cada router a lo largo del camino entre origen y destino especificando los requerimientos de clase y recursos de la sesión iniciada. La reserva permanece válida siempre y cuando la sesión esté activa, pero expira si no se refresca periódicamente. Usando este modelo de servicios, si hay N sesiones individuales pasando a través de un router en un dado instante, el router necesitará mantener la información de estado necesaria para las N sesiones.

Un aspecto importante de este modelo es que la reserva de recursos se extiende a lo largo de toda la ruta (e2e path) de los paquetes de datos. Si la ruta cambia, entonces la reserva se rehace automáticamente para seguir la nueva ruta. Esto es también permitido por medio del uso de la característica “soft-state”. El modelo de servicios es unidireccional, vale decir, si una sesión de comunicaciones en ambos sentidos necesita QoS deberá reservar recursos en ambas direcciones.

A modo de comentario, es interesante decir que IntServ agrega dos clases de servicios adicionales al modelo “best-effort” usado en Internet: “guaranteed service” y “controlled load service”.

RSVP es un protocolo de reserva orientado al receptor que es usado dentro de una red IntServ para señalizar los requerimientos de QoS de una sesión de aplicación a lo largo del camino entre origen y destino.

El proceso de reserva comienza con el emisor enviando un mensaje PATH hacia el receptor, que atraviesa todos los routers a lo largo del camino. Este mensaje graba todos los routers intermedios como parte del forwawrding path y calcula los parámetros de red e2e. Cada mensaje PATH transporta un objeto de especificación de tráfico llamado Tspec que describe el perfil de tráfico generado por el origen, y tiene los siguientes parámetros: rate, bucket, peak rate, minimum policed unit y maximum packet size. El mensaje PAT además transporta un objeto de especificación de divulgación denominado Adspec que se usa en el cómputo de los parámetros de QoS acumulados a lo largo del e2e path.

Cuando el mensaje PATH alcanza el receptor, el mismo responde al emisor con un mensaje RESV que transporta la especificación de reserva (Rspec) contenida en un objeto FlowSpec. Este mensaje, si es aceptado por todos los routers a lo largo del camino (mensaje RESV de confirmación), establece la reserva actual y “filter on” estos routers intermedios. A este proceso se lo conoce como control de admisión.

Si un error llegara a ocurrir o no existen suficientes recursos para ser asignados, entonces se genera o bien un mensaje PATHerr o RESVerr por el router correspondiente. Este mensaje regresa al emisor y así cualquier reserva hecha en los routers intermedios se cancela.

Finalmente, una vez que una sesión de aplicación culmina, se envían mensajes Patear y RESVtear para remover los estados de reservas en todos los routers a lo largo del camino.

11.10.2.Evaluación del modelo IntServ

IntServ con RSVP tiene las siguientes características favorables:

Flexibilidad para encontrar las necesidades de QoS: la reserva de recursos se hace por flujo y entonces se satisfacen los requerimientos de recursos de flujos individuales

QoS asegurado y determinístico: los mensajes RSVP atraviesan el mismo camino e2e que el tráfico de datos de la aplicación desde el origen al destino y establece estados de reserva en cada router a lo largo del camino. Esto hace que el proceso de reserva sea exacto en términos de la provisión del QoS requerido.

Ajustes a los cambios de rutas: las reservas RSVP son estados blandos (decía “soft”) y necesitan ser refrescados periódicamente. El proceso de refresco cualquier cambio en las rutas durante el tiempo de vida de una sesión y así ajusta el camino de reservas de acuerdo a ello.

Soporte de comunicaciones multicast: dado que RSVP es un protocolo orientado al receptor, ya que múltiples receptores se unen a un multicast y responden al origen con mensajes de RESV. Los recursos requeridos son así acordemente reservados.

Sin embargo, al día de hoy, el despliegue de IntServ ha estado limitado por las siguientes razones:

El modelo IntServ carece de escalabilidad. Esto es una consecuencia directa de la reserva de recursos por flujo y el tratamiento del tráfico en los routers intermedios y así no escala en los routers del centro o en los backbones de las redes.

Las aplicaciones deben esperar hasta que la reservación usando RSVP se complete. Esto puede retardar el tiempo de arranque y puede ser inaceptable para ciertas aplicaciones de tiempo real que requieren una respuesta inmediata de acuerdo a límites estrictos. Esto se hace más problemático para sesiones con un tiempo de vida corto como http, donde el tiempo de establecimiento de la sesión es mucho más largo que el tiempo de transferencia de datos y se torna así mucho más significativo.

Dado que la reserva de recursos y los cálculos de QoS son hechos a priori y tan cerca como sea posible del perfil de tráfico especificado

dado por las aplicaciones, cualquier cambio imprevisto o importante en el tráfico de datos a causa de una actualización o cambio de requerimientos de la aplicación pueden tener efectos impredecibles a menos que se haga de nuevo una negociación o reserva usando los nuevos perfiles de tráfico.

IntServ no es compatible con el protocolo de seguridad IPSec, debido a la clasificación multicampo requerida en cada router del camino para identificar flujos individuales. Dado que IPSec encripta los headers de la capa de transporte de un paquete, los routers no tienen acceso a estos headers para poder poder llevar a cabo la clasificación. Sin embargo, este problema fue resuelto con la introducción del flow label de IPv6, el cual identifica el flujo mirando sólo en el header de la capa de red sin necesidad de la información del header de la capa de transporte.

11.11.Servicios Diferenciados