Resumen

  • En RSVP, el receptor inicia una petición que avanza salto a salto hacia el emisor. Cada nodo decide por separado si hay recursos, si existe permiso y qué estado de clasificación y planificación instala.
  • El estado se borra cuando faltan refrescos coincidentes, y ResvConf no garantiza servicio extremo a extremo. Una afirmación responsable debe conservar ruta, época, decisiones locales, instalación y resultado observado.

Una promesa que incluye su propio olvido

El fallo más sano de RSVP ocurre en silencio: un temporizador vence y el router elimina una reserva que ya no recibe refrescos. No hace falta que una autoridad central certifique el final ni que un único mensaje de borrado llegue intacto a toda la ruta.

RFC 2205 llama a este diseño «estado blando». Los mensajes Path y Resv crean y refrescan el estado; el intervalo de limpieza lo retira cuando deja de llegar evidencia coincidente. La red puede tolerar una cantidad acotada de mensajes perdidos, pero no conserva indefinidamente una intención antigua.

Por eso «reservado» no es un atributo eterno del flujo. Es una frase temporal: este receptor, para esta sesión, sobre esta ruta, bajo estas decisiones y hasta este vencimiento. Omitir la fecha y el ámbito transforma una propiedad operativa en una etiqueta comercial.

El camino baja; la solicitud sube

RSVP es simplex y orientado al receptor. El emisor envía Path en la dirección de los datos. Cada nodo guarda estado de camino y el salto anterior. Cuando el receptor decide pedir servicio, envía Resv en sentido inverso, salto a salto, hacia los emisores correspondientes.

La arquitectura sirve tanto a unicast como a grupos multicast cambiantes. Varias solicitudes pueden fusionarse al subir. El flowspec que un nodo reenvía puede ser distinto del recibido, ya sea por ajuste local o por la combinación de ramas.

Una captura de Resv acredita una solicitud en un punto. No acredita el resto de la ruta. Una captura de Path acredita que cierto nodo conocía un camino; no demuestra que la petición inversa atravesara cada dominio. El protocolo obliga a tratar esos dos rastros como pruebas complementarias.

Recursos y permiso nunca fueron la misma decisión

En cada salto, control de admisión pregunta si existen recursos suficientes. Control de política pregunta si el usuario puede reservarlos. RFC 2205 exige dos síes.

Después viene otra operación: programar el clasificador y el planificador de paquetes, o el mecanismo equivalente de la capa de enlace. RSVP transporta parámetros de calidad y política como datos opacos; los sistemas locales conservan la autoridad para interpretarlos y aplicarlos.

La cadena tiene al menos tres fronteras. Capacidad no es autorización. Autorización no es estado instalado. Estado instalado en una interfaz no es servicio medido de extremo a extremo. Un informe que salta de la primera frontera a la última no describe RSVP; lo simplifica hasta hacerlo irreconocible.

RFC 2208 advertía de costes de procesamiento y memoria, agregación, seguridad y políticas al pensar en despliegues amplios. Es una advertencia histórica, no una cifra de uso actual. Su valor aquí es recordar que una especificación de señalización nunca sustituyó al conjunto de controles locales.

Un acuse positivo con una cláusula negativa

El receptor puede pedir confirmación. Si una solicitud llega a un punto donde ya existe una reserva igual o mayor y la fusión evita enviarla más lejos, ese nodo puede devolver ResvConf.

RFC 2205 limita de inmediato la lectura: recibir ResvConf no ofrece garantías. El ejemplo del propio documento permite que una segunda solicitud reciba confirmación mientras la primera, con la que se fusionó, todavía no alcanzó al emisor y puede fallar. Después de ResvConf puede llegar ResvErr.

La inferencia legítima es pequeña: un nodo identificado trató una solicitud de confirmación usando el estado que veía. No sabemos todavía si todos los saltos admitieron, si todos los planificadores aplicaron, si la ruta siguió igual ni si los paquetes recibieron el servicio esperado.

ResvConf es útil como recibo de señalización. Se vuelve peligroso cuando un panel lo convierte en certificado de resultado.

La ruta anterior no se corrige: se deja vencer

Path y Resv son idempotentes. Ante un cambio de ruta, el siguiente Path crea estado en el nuevo trayecto y futuros Resv establecen allí la reserva. El segmento abandonado queda sin renovación y caduca.

PathTear y ResvTear pueden acelerar el borrado, pero tampoco tienen entrega fiable. Su pérdida no rompe el protocolo porque el temporizador termina retirando el estado. El control no depende de una transacción global perfecta.

Existe además la reserva parcial. Si un nodo rechaza por admisión, el estado en saltos posteriores puede mantenerse para ofrecer servicio parcial o recuperarse pronto de una oscilación transitoria. Dos afirmaciones aparentemente contradictorias pueden ser ciertas: este router conserva estado, pero no hay una reserva completa hasta el emisor.

El recibo debe localizar el límite del fracaso y el alcance de lo que queda. Un solo Booleano no puede hacerlo.

Menos bytes, las mismas obligaciones

RFC 2961 atacó el coste de refrescar Path y Resv completos. Introdujo identificadores de mensaje, acuses por salto para determinada señalización y Summary Refresh, capaz de renovar estado conocido mediante identificadores.

La compresión no convierte la reserva en permanente. Summary Refresh debe preservar la sincronización del estado blando. Si no existe el estado referido, el vecino puede responder con un NACK. El ACK demuestra recepción local de un mensaje; no demuestra calidad extremo a extremo.

Conviene guardar cuatro relojes sin mezclarlos: época de la solicitud, temporizador de cada nodo, época MESSAGE_ID entre vecinos y ventana de medición del plano de datos. Todos pueden avanzar a ritmos distintos.

Preguntar a los routers tampoco mide la experiencia

RFC 2745 define DREQ y DREP para recorrer nodos RSVP y reunir su estado Path o Resv. Es una herramienta de diagnóstico potente: muestra dónde aparece, cambia o falta la información de control.

Pero la respuesta puede fragmentarse, terminar antes por error, volver por otra ruta, tropezar con filtros o agotar el tiempo. Incluso perfecta, es una fotografía de memoria distribuida. No observa por sí sola la configuración real del planificador ni la pérdida y demora que experimentó la aplicación.

Un diagnóstico amplía la evidencia. No borra la frontera entre plano de control y resultado.

Poner un nombre humano sin fabricar autoridad

El Datatracker de IETF incluye a Lixia Zhang entre los autores de RFC 2205. Su biografía de UCLA sitúa la concepción y desarrollo de RSVP durante su etapa en Xerox PARC. La especificación nombra a Robert Braden como editor y a Zhang, Steven Berson, Shai Herzog y Sugih Jamin como autores, además de reconocer una colaboración más extensa.

Internet Hall of Fame relaciona el trabajo de Zhang con RSVP y con el uso posterior de RSVP-TE. Esa semblanza institucional no es un censo de operadores, y RSVP-TE no debe confundirse con el protocolo original de servicios integrados.

La atribución segura es coautora, codiseñadora y contribuyente. No inventora única, operadora actual, dueña del consenso ni garante de una red. El límite no reduce su importancia; evita usar el prestigio de una persona para cubrir pruebas que corresponden a receptores, routers, administradores y mediciones.

El expediente de siete piezas

Primero, camino: emisor, sesión, ruta, salto previo y hora. Segundo, solicitud: receptor, Resv exacto, filtros, flowspec, confirmación y época. Tercero, autoridad: admisión y política en cada dominio relevante.

Cuarto, instalación: destino del clasificador y planificador, resultado de transacción y lectura posterior. Quinto, vigencia: último refresco, intervalo, vencimiento, Summary Refresh y NACK. Sexto, confirmación o diagnóstico: qué nodo habló y qué estado observó. Séptimo, resultado: trayecto efectivo y servicio medido durante una ventana.

Ninguna pieza hereda el significado de las demás. Cuando las siete se unen, «reservado» deja de ser una promesa decorativa y se convierte en una conclusión limitada, reproducible y revocable.

Fuentes