| Artículos | 01 DIC 2000

Mejor transporte, por favor

Tags: Histórico
Protocolo de reserva de recursos
Juan Blázquez.
El concepto de aldea global al que Internet iba a dar sustento, se ha quedado como otro objetivo romántico más y ha sido rápidamente modificado por la idea de bazar global. Esta transformación de la Red en una infraestructura comercial es la que deja al descubierto que Internet no está diseñada para ser lo que es hoy y, menos aún, para lo que pueda llegar a ser en el mañana. Y la industria, por supuesto, reacciona.

Las carencias de Internet son una realidad patente a medida que su uso se incrementa y se tratan de exprimir todas sus posibilidades, una evidencia que sufren en mayor medida los responsables de red y proveedores de servicio que se las ven y se las desean para que sus sistemas puedan asumir el tráfico, cada vez más intenso y complejo, que generan unos usuarios insaciables de recursos.
En los comienzos de Internet, se primó en su diseño la funcionalidad y conectividad frente a cualquier otra consideración. Importaba y se buscaba lograr conectar. Nadie, a principio de los años setenta, podía imaginar el escenario actual de la Red sin que le tomaran por un visionario desquiciado. Si esta premisa de conexión a toda costa provocó que Internet haya crecido, y siga creciendo, a ritmo vertiginoso, también ha traído consigo otros problemas y limitaciones que lastran profundamente su actual e inevitable evolución y frente a ellos, la industria trata de dar la respuesta oportuna para poder implementar una verdadera red global sin cortapisas en seguridad, direccionamiento, rendimiento y capacidad.
En cuanto a rendimiento y capacidad, las empresas que mantienen líneas de negocio en Internet necesitan disponer de un soporte de red que responda con un servicio siempre en condiciones fiables que garantice a sus clientes disponibilidad, comodidad y variedad de servicios. Otro tanto les ocurrirá a aquellas otras organizaciones, en las que las facilidades de conexión de Internet pueden hacer muy atractivos el teletrabajo o el trabajo en equipo con miembros muy dispersos geográficamente, pero siempre y cuando tengan resuelta la necesaria operatividad de los recursos necesarios.
Estos escenarios y servicios, tomados a modo de ejemplo, no resultan ya de ciencia-ficción y la presión de su demanda choca frontalmente con la tecnología actualmente desplegada en la Red, que no es capaz de asumirla en óptimas condiciones. El tráfico de paquetes que hoy viaja por Internet se basa en ser procesado en cuanto sea posible, según las circunstancias de la red, sin ninguna garantía sobre el propio proceso, ni cuando tendrá lugar ese tratamiento. La tecnología que gira en torno a Ipv4, por diseño, no es capaz de asimilar ni responder a las expectativas que hoy por hoy se han generado en la red de redes.

Calidad de servicio, la clave
Ante la perspectiva de obligada remodelación de la infraestructura de Internet, el IETF, Internet Engineering Task Force, como responsable de la dinámica de la Red, ha propuesto y está definiendo el modelo de servicio que se utilizará en el futuro inmediato, entendiendo como servicio el conjunto de características que influyen en la transmisión de los datos, como pueden ser retardos, pérdidas, rendimiento, tasa de transferencia, y otros. Estos aspectos de la transmisión son los que condicionan la conexión y son los que determinan la calidad de la comunicación resultante que obtiene el usuario. De esta idea surge el concepto de QoS, Quality of Service, base en la que se apoya la tecnología emergente con la que se pretende responder a la evolución que se demanda de Internet.
Para que se de la calidad de servicio que exigen las aplicaciones que se ejecutan en tiempo real dentro de Internet y otros programas sensibles a las condiciones de la transmisión, el reto más perentorio hoy en la Red, es imprescindible que se establezcan los mecanismos necesarios para controlar el retardo de los paquetes entre los extremos implicados en la comunicación y, a la vez, que no obligue a la utilización de todo el ancho de banda disponible y que sea factible su adecuado reparto para que puedan coexistir con el resto de aplicaciones que no presentan una influencia tan crítica en las condiciones del flujo de datos. De otro modo, los operadores de la infraestructura no podrán ofrecer todos los servicios a precios asequibles manteniendo la rentabilidad. Es decir, se hace ineludible poder diferenciar el tipo de tráfico para que en función de su clasificación se le pueda asignar los recursos disponibles necesarios.
En este sentido, el IETF ha establecido dos tipos de servicios susceptibles de implementarse en Internet. Por una parte, los Servicios Integrados, que definen un modelo que incluye los servicios de mejor esfuerzo, tiempo real y compartición controlada de los enlaces. Por otra parte, los Servicios Diferenciados, con los que se podrá personalizar los servicios que obtienen los usuarios basándose en la asignación de diferentes niveles de servicio según el usuario. Este último modelo se encuentra aún en fase de discusión por parte de la comunidad Internet, mientras que los Servicios Integrados ya están en fase de desarrollo.
Para que en el modelo de Servicios Integrados los programas puedan escoger entre distintos niveles de entrega de sus paquetes, es necesario que existan a lo largo del camino los mecanismos necesarios que proporcionen y gestionen QoS y un procedimiento estándar que permita la obtención de la Calidad de Servicio a lo largo de toda la conexión.

RSVP la implementación
Así surge RSVP (ReSerVation Protocol), protocolo de reserva de recursos, un protocolo de control de la red que permite que los programas que van a trabajar en Internet puedan obtener la calidad de servicio que sus flujos de datos puedan requerir. Se trata de un protocolo totalmente emergente que se encuentra aún en fase de normalización por parte del IETF, que está desarrollando su estandarización partiendo de los trabajos iniciales que se realizaron en la Universidad del Sur de California, con la participación de Xerox, donde fue concebido.
Este protocolo no es, en contra de lo que pudiera parecer, un protocolo de enrutamiento. Es un protocolo que se inscribe dentro de la capa de Transporte del modelo de conectividad OSI y se apoya en las tablas de rutas dinámicas que manejan los protocolos de enrutado clásicos para establecer una conexión a modo de circuito virtual entre emisor y receptor o receptores implicados.
Para RSVP el flujo de datos es simplemente una secuencia de paquetes que tienen un mismo origen, uno o varios destinos, según sea la difusión, unicast o multicast, y una calidad de servicio, todo ello caracterizado mediante sesiones. Una sesión RSVP es cada torrente de datos que el protocolo maneja de forma independiente.
Las especificaciones de operación de este protocolo se materializan en un programa, en un demonio, RSVP estructurado en módulos, cada uno de ellos con unas funciones específicas. Por una parte, están el módulo de Control de Admisión y el módulo de Control de Política. El primero se encarga de determinar si el nodo tiene los recursos solicitados disponibles para soportar la calidad de Servicio pedida. El Control de Política determina si el solicitante tiene los permisos necesarios para poder disponer de los recursos que solicita. En otro lado, se encuentra el motor de la reserva, el módulo de Clasificación, encargado de recepcionar los paquetes para determinar su ruta y QoS necesaria y el módulo Esquemático, al que se le encomienda la transmisi
Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios