IntServ

Servicios Integrados o IntServ constituyen una arquitectura cuyo cometido es gestionar los recursos necesarios para garantizar calidad de servicio (QoS) en una red de computadores. El concepto que los servicios integrados proponen para cumplir con su cometido, requiere de una nueva arquitectura de protocolos que es difícilmente escalable. Esto se debe a que funciona realizando una reserva extremo a extremo de recursos en los elementos que conforman la red a nivel de aplicación.

El notable crecimiento de Internet ha originado un importante crecimiento del tráfico. Este hecho, causado por la aparición de un diverso tipo de aplicaciones ya sean web, video en tiempo real, conversaciones de voz, aplicaciones P2P y un largo etcétera, ha incitado a los expertos a buscar soluciones para controlar y gestionar este tráfico. Una de las soluciones adoptadas en los últimos años es el uso de servicios integrados, que de todas las soluciones propuestas para resolver esta problemática, podría considerarse como la más drástica debido a que sugiere modificaciones en todos los equipos que conforman la red de redes.

El diseño actual de las transmisiones sobre IP da la misma prioridad de envío a todos los paquetes, sin embargo, debido a los diferentes tipos de servicios que circulan ahora por la red.

Supóngase un caso en el que un usuario está utilizando simultáneamente dos aplicaciones multimedia diferentes: una para realizar llamadas a través de VoIP y otra para intercambiar información entre dos servidores FTP. Si este usuario decidiese dar preferencia a su llamada VoIP y, por ejemplo, y asignar a este servicio un ancho de banda mínimo, para una correcta comunicación ( recordemos que su ancho de banda total está siendo compartido con otros recursos como por ejemplo el intercambio de ficheros FTP), el usuario necesitará una calidad de servicio distinta para sus dos aplicaciones ( voz IP y FTP ). En otras palabras, estará pidiendo que los paquetes IP de su conversación de voz tengan preferencia sobre sus paquetes FTP.

Otro ejemplo podría ser el escenario de la reproducción de video y audio ( streaming ). Si se diferencia entre streaming almacenado en un servidor y streaming en tiempo real, este mismo usuario no tendrá problema en tener que esperar cierto tiempo para poder visionar un streaming almacenado pero, en cambio, no tendrá un servicio tan satisfactorio si el streaming está siendo emitido en directo.

Así, surgen para dar esta calidad de servicio dos arquitecturas generales:

Antes de describir las diferentes funciones, vale la pena definir el concepto de flujo. Se considerará por flujo al tráfico continuo de datos generados por un usuario o una aplicación y que requieren una misma calidad de servicio. En la versión de IPv4 un flujo estará definido a nivel de transporte por el protocolo utilizado (ya sea TCP o UDP), por sus puertos y por las direcciones IP origen y destino. En la versión de IPv6 existe además un campo creado expresamente para esta función, que junto a sus direcciones origen y destino caracterizarán un flujo. Este campo recibe el nombre de etiqueta de flujo.

Dentro de la arquitectura de servicios integrados, podrían distinguirse las siguientes funciones principales:

Control de admisión: como se ha dicho anteriormente, antes de enviar la información a través de la red se reservarán los recursos en función de la QoS que se necesite. Para esto hay implementado un protocolo de reserva de recursos denominado RSVP (ReServation Protocol). En una nueva sesión:

Para la comunicación de RSPEC y TSPEC a través de los routers que conforman la red, se utilizará el protocolo RSVP.

Enrutamiento: Los routers se basarán en la QoS de cada flujo de datos para enrutar los paquetes. Para ello los paquetes serán clasificados por flujos. Una vez clasificados pasarán por un organizador que dictará el modo en que se envían los paquetes. Los paquetes serán enviados a una de las colas con QoS, o bien, si no se ha especificado QoS alguna, serán enviados a la cola por defecto asociada al servicio Best Effort.

Disciplina de servicio: Se podría considerar como disciplina de servicio al modo de funcionamiento con el que trabajarán las colas para llevar a cabo la mencionada diferenciación atendiendo a la QoS de los flujos. Para tratar la disciplina de servicio existen varias técnicas:

Descarte de paquetes: Con el fin de evitar colapsos en las redes de comunicación se realizan controles de congestión. A continuación se introducirán tres métodos para realizar control de congestión mediante descarte de paquetes.

RSVP o protocolo de reserva de recursos, es un protocolo de señalización que permite a los usuarios comunicar a la red sus requerimientos de forma robusta y eficiente. Aunque no hay nada que impida la utilización de RSVP en tráfico unicast, originalmente este protocolo había sido pensado para tráfico multicast. En multicast, es común ver distintos flujos de video y audio en tiempo real y estos flujos requieren distintas calidades de servicio.

En el protocolo RSVP vale la pena destacar el concepto de ruta (path). Una ruta define el camino que llevará el flujo de información desde el router emisor hasta el router receptor. Así, cada uno de los paquetes que pertenezcan a un flujo específico de información seguirán la misma ruta. Por lo tanto cada emisor enviará periódicamente un mensaje de ruta por cada flujo de información que genere. Éste contendrá información acerca de la calidad de servicio de cada tipo de flujo. RSVP se vale de las tablas de rutas de cada router para enviar sus mensajes RSVP ya que este protocolo, por sí solo, no trabaja en labores de enrutamiento.

Se destacarán los dos mensajes principales:

Objetivos principales de RSVP:

Aclaraciones respecto a RSVP:

Vale la pena mencionar que, aunque RSVP sea un protocolo Internet también es un protocolo orientado a conexión ya que los routers tendrán que almacenar información en relación al estado de cada flujo para el que se efectúa una reserva.

Pueden consultarse las especificaciones del protocolo completo en el enlace externo correspondiente a RFC-2205.

Aunque a mediados de los 90 la idea Intserv/RSVP generó una gran expectativa, con el paso del tiempo el interés por esta arquitectura se hizo decreciente. El motivo principal fueron los problemas de escalabilidad causados por la necesidad de almacenar y mantener información de estado en cada router. Estos motivos aplicados a una gran red como es internet, apartan RSVP de la realidad. Además, los fabricantes de routers tampoco realizan implementaciones eficientes de RSVP debido a su elevado coste hardware. Recientemente, se ha vuelto a hablar de RSVP por su aplicación en MPLS e ingeniería de tráfico, ya que en estos casos la cantidad de flujos es menos elevada, lo que permite hacer implementaciones a menor coste, haciéndolo más asumible.