Resumen

  • RFC 3473 permitió enviar un Notify de RSVP-TE directamente a un nodo no adyacente registrado y usar el ACK de RFC 2961 como prueba de recepción.
  • Notify no sustituía PathErr ni ResvErr: el ACK probaba la llegada de la alarma, no la convergencia del estado, el cambio de protección o el regreso del servicio.

Una alarma puede llegar antes que la reparación que anuncia. RFC 3473 convirtió esa diferencia en una propiedad explícita del protocolo.

Publicado en enero de 2003, el documento llevó las funciones de GMPLS a RSVP-TE. Codificó etiquetas generalizadas, enlaces bidireccionales, restricciones, protección, canales de control separados y recuperación. RFC 3472 hacía el trabajo paralelo para CR-LDP. Notify, en cambio, respondía a una cuestión muy concreta: cómo informar pronto al nodo capaz de reaccionar cuando ese nodo no era el vecino inmediato del fallo.

Path podía llevar una Notify Request para avisos hacia arriba; Resv podía llevarla para avisos hacia abajo. El objeto contenía la dirección IPv4 o IPv6 del Notify Node. Los nodos debían guardar esa dirección con el estado correspondiente y propagar normalmente la petición.

La dirección no era necesariamente inmutable. La política local podía cambiarla al reenviar. Si aparecían varias solicitudes, solo la primera tenía significado. Y la mera presencia de Notify Request no garantizaba que más tarde se produjera un Notify.

Ante un error apropiado, el detector podía dirigir el mensaje a un nodo no adyacente. Los nodos intermedios que no eran el destino lo reenviaban intacto, o el remitente lo encapsulaba en una cabecera IP nueva con la dirección final. Notify no usaba Router Alert. El aviso seguía así una ruta probatoria distinta del error ordinario salto a salto.

ERROR_SPEC identificaba el error y el nodo detector o enlace fallido. Los descriptores delimitaban las sesiones afectadas. Un mismo fallo podía originar avisos en ambas direcciones, pero estaba prohibido emitirlos sin haber recibido la solicitud adecuada.

RFC 2961 aportaba Message ID y ACK. El receptor debía acusar el Notify. Esa transacción confirmaba que un mensaje RSVP identificable había llegado a un destino concreto.

No confirmaba la verdad física del error, la retirada de estado en cada nodo, la capacidad de la ruta alternativa, la conmutación óptica, el retorno de los paquetes ni el resultado de la aplicación. RFC 3473 fue explícito: Notify no reemplazaba los mensajes de error existentes. Podía acompañar a PathErr o ResvErr, no certificar todo su trabajo.

Path_State_Removed separaba todavía más las pruebas. Un nodo podía indicar dentro de PathErr que realmente había descartado el estado Path. El ACK de la alarma y la constancia de esa acción local eran recibos diferentes. Ninguno resumía por sí solo la ruta completa.

Los avisos con el mismo destino y ERROR_SPEC podían agruparse. El método quedaba a la implementación; con temporizador, el valor predeterminado era un milisegundo. Agrupar reducía carga durante una avería, pero la hora del mensaje no era necesariamente la de cada evento, ni las sesiones agrupadas compartían una recuperación atómica.

El estado administrativo mostraba la necesidad de una segunda prueba. Tras enviar Down mediante Notify, el emisor debía recibir un Path con Down dentro de un plazo configurable, treinta segundos por defecto. Sin él, iniciaba eliminación y errores adicionales. El protocolo no confundía su aviso inicial con el efecto esperado.

También podía fallar solo el canal de control. Durante una espera de reinicio, el reenvío y el estado RSVP podían conservarse. Un aviso de canal degradado no probaba pérdida de datos; uno de canal activo tampoco garantizaba que todo el estado o el servicio hubieran vuelto.

El envío no adyacente afectaba además a la seguridad. RSVP dependía normalmente de integridad salto a salto. RFC 3473 recomendó IPsec para el mensaje directo o permitió desactivarlo. Aun autenticado, el aviso y su ACK demostraban hechos limitados sobre emisor, contenido y recepción, no sobre la realidad física o comercial descrita.

RFC 4090 y después RFC 4872 y RFC 4873 añadieron mecanismos y ámbitos de recuperación. No hicieron equivalentes el aviso, la decisión, la conmutación y la observación del servicio.

Según el principio de código en ejecución de Heng Lu, Notify seguía siendo una instrucción simbólica hasta observar la transición prevista. La especificación mínima dejaba agrupación y política en manos locales. Las capas de realidad impedían que el ACK heredara la autoridad de una recuperación realmente comprobada.

Un registro íntegro conserva la solicitud, el destino efectivo, ERROR_SPEC, sesiones, Message ID, envío, recepción y ACK. Por separado guarda PathErr o ResvErr, eliminación de estado, protección o teardown, programación física, señal, tráfico y aplicación. Solo esa cadena completa permite escribir «recuperado».

Fuentes