2. RSVP: PROTOCOLO DE CONFIGURACION DE RESERVA DE RECURSOS
2.8. MITOS SOBRE RSVP
Aún existen varios mitos relacionados, con la implementación de RSVP(algunos de ellos, ya comentados), estos incluyen:
• Escalabilidad: RSVP es por flujo, pero esto no escala en el backbone.
• Control de admisión: RSVP no esta disponible para ejecutar control de admisión sobre gateways de voz.
• Retardos en establecimiento de las llamadas: El tiempo necesario para establecer una reservación punto a punto es muy alto.
Las secciones siguientes discuten a mayor profundidad cada una de estas afirmaciones, los ejemplos están relacionados con ejemplos de implementación desarrollados por la empresa Cisco.
2.8.1. Escalabilidad
Si percibimos RSVP como la arquitectura de Intserv, es probable que esta afirmación sea cierta(como se comento en la sección 2.7). Intserv utiliza RSVP sobre una base por flujo, lo que puede originar problemas de escalabilidad, sin embargo, estos temores son exagerados; por ejemplo los enrutadores Cisco han demostrado la capacidad para manejar mas de 10000 flujos RSVP con mínimo impacto en términos de CPU y Memoria. La implementación de RSVP no genera problemas de escalabilidad para redes pequeñas.
Para grandes redes, diversos fabricantes y Cisco recomiendan la implementación de una combinación de las dos arquitecturas de QoS: Intserv con Diffserv( como se define en el Rfc2998) ; esta estrategia, discutida en la sección 1.11.1.2 de este documento, es una solución muy escalable; Intserv se usa en la orilla de la red para proporcionar tratamiento por flujo y control de admisión, mientras que Diffserv se desarrolla en el centro(core), lo que permite que el trafico se maneje de manera agregada. La versión 12.2(2)T del software Cisco IOS, fue el primero en introducir esta integración (
Intserv-Diffserv ) y desde hace aproximadamente 1 año, la versión esta disponible en
los productos comerciales(enrutadores).
La estrategia de envío de refrescos para cada estado(correspondiente a un flujo), no es escalable. El Rfc2961( Refresh Reduction) es un mecanismo que IETF(grupo Internet Engineering Task Force) ha estandarizado para reducir los mensajes de refresco. La estrategia, consiste en enviar estos mensajes de refresco, no por flujo sino un mensaje único agregado(varios flujos). El software Cisco IOS, soporta esta estrategia desde finales del año 2002.
El IETF ha estandarizado un esquema para agregar RSVP: rfc3175: RSVP agregado. Esto permite que se definan puntos de agregación o desagregación, donde se crea una zona donde múltiples estados “paralelos” por flujo se convierte en un único estado. Cisco y otras empresas están investigando activamente la implementación de esta funcionalidad y a finales de este año debe estar disponible en los productos.
2.8.2. Control de admisión
Contrario al pensamiento generalizado, RSVP resulta ser una ideal selección para la administración del control de admisión. Es el único mecanismo conocido y estandarizado para proporcionar control de admisión punto a punto. RSVP ha sido una parte integral del Software Cisco IOS, desde su invención a mediados de los años 90. La sincronización de llamadas para H.323 se agregó en la versión de 12.1(5)T del software Cisco IOS.
La compresión del encabezado IP(cRTP) es una funcionalidad clave para la voz. RSVP no considera la estrategia de control de admisión en ancho de banda comprimido, lo que se hace es “inflar” el ancho de banda de tal forma que RSVP haga el control de admisión de forma adecuada . Este problema esta siendo resuelto y RSVP soportará la compresión del encabezado IP en la sexta modificación de la versión 12.2T del software Cisco IOS.
El control de admisión usando RSVP esta disponible en los primeros gateway de voz que incluye los enrutadores cisco series 2600, 3600, el servidor de acceso universal Cisco AS5300, Cisco AS5350,AS5400 y los gateways universales AS5850.
2.8.3. Retardo en el establecimiento de la llamada
Este problema es dependiente del desarrollo especifico que se haga del protocolo. Existen diversas razones que pueden originar retardo en la configuración de una reservación punto–a- punto; usualmente hay dos causas principales:
• Los mensajes de control RSVP no se marcan con una prioridad mas alta y/o
• Existen perdidas de mensajes de control RSVP en la ruta de la llamada.
Desde la versión 12.2T de Cisco IOS, los mensajes de control de RSVP pueden ser marcados a través de Diffserv(DSCP: Diffserv Code Point), asegurando de esta manera, que estos sean tratados con una prioridad alta. Esta estrategia minimiza los potenciales retardos causados por los algoritmos de planeación en los nodos(scheduling) de acuerdo a los mensajes de control RSVP.
La pérdida de mensajes de control RSVP esta relacionada con la situación antes descrita; suponga que estos mensajes no se marcan como de alta prioridad, los mecanismos como WRED tienden a borrar este tipo de paquetes en situaciones de congestión, de tal forma que se aumenta el tiempo en el establecimiento de la reservación.
El Rfc2961 define el concepto de “mensajeria confiable RSVP”: el proceso RSVP continuamente retransmite los mensajes hasta que se recibe un mensaje explícito de asentimiento. Esta estrategia esta disponible desde la quinta modificación de la versión 12.2T del software Cisco IOS.
La latencia causada por el proceso RSVP en cada enrutador para la ruta de los mensajes de control es extremadamente pequeña. Por ejemplo, el valor es cerca de 10ms por nodo (pruebas en enrutadores Cisco series 3600 y 7200 ), de tal forma que una ruta de 10 saltos podría tomar una décima de segundo para el establecimiento de la llamada(la reserva en este caso). Esto valor no se debe confundir con la latencia que se establece durante la duración de una llamada.
En conclusión, RSVP es una solución viable(especialmente en redes corporativas) . El
protocolo ha demostrado un gran valor agregado y actualmente esta siendo desarrollado globalmente.