Servicios integrados

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.

Historia

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.

Introducción

El diseño actual de IP da la misma prioridad en el envío a todos los paquetes, sin embargo, resulta de capital importancia establecer calidad de servicio a ciertas comunicaciones que, por su contenido y requisitos, no son aptas desde el punto de vista “best effort” que ofrece.

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, asignar a la misma un ancho de banda mínimo satisfactorio para una correcta comunicación (ancho de banda que no está teniendo dado que sus recursos están siendo compartidos con el intercambio de ficheros FTP), el usuario estará pidiendo una calidad de servicio distinta para sus dos aplicaciones. En otras palabras, estará pidiendo que los paquetes IP de su conversación de voz tengan preferencia sobre sus paquetes FTP.

Otro ejemplo englobaría al visionado de video y audio por 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:

• Servicios Diferenciados o Diffserv, basada en un marcado previo definido por clase de los paquetes, antes de ser enviados por el router.
• Servicios Integrados o Intserv, basada en una reserva extremo a extremo de recursos que irá en función de la QoS que se requiera para cada aplicación.

Funciones de la Arquitectura de Servicios Integrados

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:

1. Control de admisión
2. Enrutamiento
3. Disciplina del servicio
4. Descarte de paquetes

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:

• Declaración de los requerimientos de QoS: Se realizará mediante RSPEC (Request SPECification)
• Caracterización del tráfico que será enviado a la red: Se hará mediante TSPEC (Traffic SPECification).

TSPEC define el servicio de cada flujo, donde se pueden diferenciar las siguientes categorías:

• Servicio garantizado: la tasa de transmisión acordada está garantizada. También se garantiza la ausencia de pérdidas. Este servicio es el idóneo para aplicaciones en tiempo real.
• Servicio controlado: la tasa de transmisión acordada se cumple si la red no está sobrecargada, la tasa de pérdidas es bastante baja. Se puede adaptar a aplicaciones en tiempo real pero es más adecuado para navegación web, FTP y aplicaciones similares ya que los routers no darán garantías estrictas.
• Servicio Best Effort: es un servicio por defecto que no tiene garantías.

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:

• FIFO (First In First Out): Es la técnica más extendida, aunque para el caso de servicios integrados resulta irrelevante. Esto se debe a que esta técnica no proporciona la opción de dar preferencia a distintos flujos de comunicación.
• WFQ (Weighted Fair Queuing): Es una técnica que proporciona múltiples colas de espera. Se asignará a cada cola de espera un determinado flujo, así se logrará un peso (W) distinto en función de cuan buena sea la QoS requerida por cada flujo. Por ejemplo: si un flujo A requiere una calidad de servicio con W=12 y un flujo B requiere otra calidad de servicio con W=1. Este tipo de disciplina enviará 12 bits de flujo A y 1 bits de flujo B por ciclo.

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.

• Tail drop: Descarta los paquetes recién llegados con el fin de no llenar las colas.
• QoS: Descarta los paquetes con menos calidad de servicio.
• RED (Random Early Detection) : Descarta continua y aleatoriamente paquetes de una manera controlada, así se estará tratando la congestión de la red antes de que se produzca. Es uno de los más utilizados.

RSVP

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 envíar sus mensajes RSVP ya que este protocolo, por sí solo, no trabaja en labores de enrutamiento.

Se destacarán los dos mensajes principales:

• PATH: con este mensaje enviado en el sentido del flujo de datos por las rutas facilitadas por el protocolo de routing, una aplicación solicita tomar parte en una sesión RSVP con comportamiento emisor. El formato del mensaje PATH contiene:

Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Policy_Data], Sender Template, Sender_Tspec y [ADSPEC]. (Los objetos entre [] pueden aparecer pero no son obligatorios)

• RESV: en consecuencia a la llegada de un mensaje PATH el receptor contesta con un mensaje RESV en el cual se indica el tipo de reserva a realizar en todo el camino. Este mensaje RESV viajará por la misma ruta seguida por su antecesor PATH pero justo en sentido contrario llegando así al emisor. El formato del mensaje RESV contiene:

Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style y Flow Descriptor List. (Los objetos entre [] pueden aparecer pero no son obligatorios)

Objetivos principales de RSVP:

• Debe permitir anchos de banda distintos a lo largo de los caminos de red.
• Permitir aplicaciones con diferentes requerimientos.
• Funcionamiento unicast y multicast.
• Mejorar el enrutamiento multicast-unicast.
• Restablecer conexiones.
• Actualización de los estados de los routers.
• Diseño modular para tecnologías heterogéneas.

Aclaraciones respecto a RSVP:

• RSVP es un mecanismo para informar cómo reservar los recursos, aunque por su parte no especifica cómo han de hacerse estas reservas.
• RSVP no proporciona la ruta que han de seguir los paquetes, este trabajo pertenece a los protocolos de routing.
• RSVP no interactúa en el seguimiento de los paquetes.

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.

Problema principal

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.

Referencias

• "Mundo IP" José Antonio Mañas, (Nowtilus 2004, ISBN 84-9763-026-2)
• "TCP/IP Tutorial and Technical Overview" Lydia Parciale, David T. Britt, (Redbooks 2006)

Enlaces externos

• RFC-1633 Servicios Integrados en Internet.
• RFC-2205 Protocolo de reserva de recursos RSVP.
• RFC-2212 Especificaciones de calidad de servicio garantizada.
• Cisco Cisco Whitepaper about IntServ and DiffServ