Resumen

  • Llevar datos y mensajes RSVP por el mismo VC reducía circuitos y latencia, pero exponía las renovaciones de estado a los descartes causados por datos no conformes.
  • Un VC de control separado ofrecía otro contrato de tráfico, no una garantía completa: admisión, transporte, renovación a tiempo y trato real de los datos exigían comprobantes distintos.

El diseño parecía una suma de eficiencias. RSVP conservaba las reservas mediante mensajes PATH y RESV periódicos. ATM asignaba recursos a circuitos virtuales con contratos de tráfico. Si los mensajes de control recorrían el VC de los datos correspondientes, no hacía falta abrir otro circuito ni esperar su señalización.

El problema aparecía al incumplirse el contrato. El descarte de tráfico no conforme podía alcanzar al paquete RSVP mezclado con los datos. RSVP soportaba pérdidas ocasionales. Una secuencia suficientemente larga podía dejar caducar el estado blando, desmontar el VC de calidad de servicio e iniciar otro establecimiento. El ahorro de señalización se convertía en una fábrica de señalización.

El estado blando necesitaba un recibo oportuno

RFC 2205 definió el estado RSVP como temporal. PATH y RESV lo creaban y renovaban; si no llegaba una actualización correspondiente antes del cleanup timeout, el estado se eliminaba. Era una propiedad útil para rutas y grupos multicast cambiantes: el estado viejo desaparecía aun sin una transacción de borrado infalible.

La repetición resolvía la pérdida aislada, no el hambre permanente. Por eso RFC 2205 recomendaba reservar un mínimo de ancho de banda para proteger los mensajes RSVP frente a la congestión.

Un contador de salida demostraba emisión, nada más. El resultado dependía del VC elegido, el contrato aplicado, la admisión, el cruce del segmento ATM, la llegada antes del plazo y la actualización del estado receptor. Un VC activo podía convivir con un estado RSVP vencido. También podía haber estado RSVP sin un VC de datos admitido. Ninguna combinación acreditaba por sí sola el servicio de la aplicación.

Cuatro formas de repartir el dominio de fallo

RFC 2382 describió cuatro familias. La señalización podía usar el mismo VC de los datos. Cada reserva podía tener un VC RSVP paralelo. Varias sesiones con la misma entrada y el mismo conjunto de salidas podían compartir un VC punto a multipunto. O se podían multiplexar varios VC punto a punto entre sesiones.

El modelo compartido minimizaba conexiones y evitaba la demora de abrir un VC adicional para PATH. Al mismo tiempo, sometía el control al trato del VC de datos. El RFC advirtió que la no conformidad podía descartar mensajes RSVP y que una pérdida excesiva llevaría a desmontar y restablecer repetidamente los VC QoS.

Usar el camino best effort era otra posibilidad. Separaba la señalización de la no conformidad del VC QoS, pero no de la congestión de la red ATM. RFC 2382 pidió una clase preferente para el control y consideró prometedora, aunque difícil, la prioridad RSVP en el planificador IP previo a ATM.

El VC de señalización dedicado compraba aislamiento. Su contrato propio evitaba que un mensaje conforme fuera descartado por el comportamiento de los datos en otro VC. El precio era duplicar el mínimo de circuitos, añadir señalización ATM y asumir latencia de establecimiento.

Multiplexar obligaba a conservar más contexto

Un VC punto a multipunto podía agrupar sesiones solo mientras compartieran una entrada y el mismo conjunto de routers de salida. Al cambiar los miembros, la entrada debía encontrar otro VC compatible, crear uno, modificar el existente o seguir enviando tráfico a una salida ya innecesaria.

Por eso la eficiencia dependía de la topología y del patrón real de tráfico. Los VC punto a punto de larga duración podían amortizarse en el núcleo y aprovechar el canal inverso, pero su cantidad seguía la combinación de nodos. Reutilizar un VC best effort ahorraba otro circuito a cambio de elevar el riesgo de perder señalización.

La evidencia tenía que registrar esa dinámica. Además del mensaje, el VC y el contrato, un circuito multiplexado requería la relación sesión-VC y el conjunto de salidas vigentes. Un inventario de VC no permitía reconstruir qué reservas habían dependido de una ruta de control fallida.

Sobredimensionar el control también podía bloquearlo

Asignar una QoS grande a la señalización no era una respuesta gratuita. RSVP enviaba mensajes con poca frecuencia, típicamente cada treinta segundos, de modo que una asignación pequeña debía bastar. Una solicitud excesiva podía ser rechazada precisamente cuando escaseaban los recursos.

El retorno a best effort contenía la misma paradoja. Si la llamada QoS fallaba por congestión ATM, el control debía atravesar esa red congestionada con menos protección. Tener un fallback no demostraba que el fallback llegara.

RFC 1755 ya intentaba evitar el connection thrashing causado por una mala gestión de conexiones. RFC 2382 expuso otra vía: pérdida en el transporte de control, caducidad del estado, desmontaje del servicio y más trabajo para reconstruirlo.

Un resultado auditable debía conservar la secuencia: generación del mensaje, asignación a VC y tratamiento, admisión del VC, cruce de ATM, renovación antes del vencimiento, permanencia del VC de datos y observación del servicio. El éxito de una etapa no se heredaba.

RFC 2382 no eligió una topología universal. Permitió escoger entre compartir, separar y multiplexar, siempre que no se fingiera que producían el mismo coste o la misma evidencia. El mínimo común era proteger y observar suficientemente el mecanismo que hacía verdadero el estado blando.