Resumen

  • RFC 3469 midió por separado la detección, la espera, la notificación, la operación de recuperación y la llegada efectiva del tráfico.
  • Una ruta preestablecida podía compartir el riesgo, carecer de recursos reservados, ofrecer calidad limitada o dejar el servicio sin protección adicional tras el desvío.

Un operador podía señalar dos líneas en el mapa y afirmar que una respaldaba a la otra. Cuando fallaba el enlace de trabajo aparecía la pregunta que el dibujo no contestaba: ¿la segunda línea llevaba paquetes, o sólo existía como objeto de control?

RFC 3469 se publicó en febrero de 2003 como documento informativo. No convirtió su taxonomía en un único protocolo estándar ni presentó resultados de una red real. Dejó fuera los reinicios. Su tarea fue describir qué debía ocurrir entre el daño inicial y una restauración que mereciera ese nombre.

El marco distinguió el reruteo de la conmutación de protección. El primero construía una ruta después del fallo. La segunda usaba una ruta preparada con anterioridad. Una red podía combinarlos: desviar rápido hacia una solución provisional, esperar la convergencia y luego trasladar el tráfico a una ruta de trabajo nueva y mejor calculada.

Por eso la mera existencia del respaldo probaba poco. La ruta podía cruzar el mismo enlace, nodo o grupo de riesgo que la activa. Podía tener señalización sin reserva de ancho de banda. Podía ser una ruta creada para otro fin y sólo precalificada. También podía haber fallado antes o caer con el mismo suceso físico.

El ciclo inicial de RFC 3469 tenía cinco intervalos. T1 llevaba del deterioro a la detección. T2 era una espera configurable, incluso de cero. T3 medía la notificación al Path Switch LSR cuando el detector no era el punto de reparación. T4 reunía las acciones de recuperación y la posible coordinación con el Path Merge LSR. T5 empezaba al terminar la última acción y acababa cuando el tráfico volvía a llegar al punto afectado.

Ese último tramo impide cerrar el incidente con una confirmación del plano de control. Una nueva etiqueta puede estar instalada mientras los paquetes aún viajan, se pierden, se reordenan o compiten por recursos insuficientes. El reloj honesto termina con evidencia del plano de datos, no con el éxito de una llamada de configuración.

La recuperación provisional tenía además un ciclo de reversión. Había que detectar la reparación, declarar despejado el fallo, esperar estabilidad si convenía, notificar, ejecutar la vuelta y observar el tráfico sobre la ruta preferida. Volver de inmediato podía amplificar una avería intermitente. Make-before-break reducía la interrupción, pero no sustituía la comprobación.

El reruteo dinámico seguía otra secuencia: estado semiestable, convergencia de protocolos, espera acotada opcional, establecimiento de una nueva ruta, conmutación y llegada de tráfico. La protección rápida no era necesariamente el final; era el margen temporal que permitía construirlo.

RFC 3469 separó la creación de ruta de la asignación de recursos. La alternativa podía estar preestablecida, precalificada o crearse bajo demanda. El ancho de banda y los búferes podían reservarse antes o después del fallo. Una ruta equivalente mantenía las garantías originales. Una ruta limitada aceptaba peores prestaciones y no debía convertirse silenciosamente en estado permanente.

Las variantes 1+1 y 1:1 repartían costes distintos. En 1+1 se enviaba una copia continua y el punto de unión elegía. En 1:1, el respaldo podía transportar tráfico de baja prioridad hasta que el flujo protegido lo desalojara. En 1:n y m:n, la cobertura dependía de qué fallos simultáneos y qué demandas había supuesto el plan, no del número bruto de caminos.

La reparación local actuaba cerca del enlace o vecino averiado y reducía el trayecto de la alarma, pero protegía un ámbito concreto. La reparación global podía rodear una zona mayor y lograr mejor separación, aunque el aviso debía alcanzar un punto distante. Una salida alternativa podía recuperar la entrega sin reconstruir la ruta exacta. Un túnel de bypass podía alojar muchas protecciones sin tener recursos para activarlas todas a la vez.

Tampoco todo el tráfico quedaba necesariamente cubierto. El marco permitía porciones protegidas y grupos de rutas. Una clase prioritaria recuperada no demostraba la suerte del resto. La antigua referencia a bits EXP debe leerse hoy con la redefinición Traffic Class de RFC 5462; lo esencial es la selección del tráfico, no el nombre histórico del campo.

La detección incluía fallos duros y degradaciones. Una degradación sólo se convertía en declaración cuando superaba un umbral provisionado. Una capa inferior podía aportar una señal más rápida. Si quien detectaba no podía reparar, enviaba un FIS al punto autorizado. Detectar, declarar, notificar y ordenar eran cuatro hechos diferentes.

Después del desvío surgía una nueva exposición. En modo revertivo, el tráfico esperaba que la ruta preferida fuera estable para volver; entretanto usaba ya su único respaldo y podía carecer de protección frente a otro fallo, mientras los recursos antiguos seguían reservados. En modo no revertivo, el desvío podía asumir el papel de ruta de trabajo, la ruta reparada convertirse en protección o crearse una pareja nueva.

El documento diferenció el tiempo de recuperación del tiempo de restauración completa. El primero sumaba T1 a T5. El segundo llegaba hasta que el tráfico ocupaba enlaces realmente dimensionados para el escenario de fallo. Sólo coincidían cuando la primera salida era equivalente y permanente.

Los criterios de comparación añadían vulnerabilidad durante el montaje, capacidad de respaldo, latencia adicional, calidad de protección, reordenamiento, estado, pérdida y cobertura. La comparación con una conmutación SONET de unos 50 milisegundos era una aspiración de ingeniería, no una medición ni una garantía de aplicación.

RFC 4090 estandarizó después fast reroute para RSVP-TE; RFC 4426, 4427 y 4428 ampliaron funciones, términos y análisis multicapa; RFC 5714 encuadró IP fast reroute. Esa evolución no certifica una implantación concreta, diversidad física ni continuidad para el usuario.

La primacía del código en ejecución de Heng Lu obliga a leer “preestablecida” y “recuperada” como símbolos hasta que coincidan tabla, recurso y tráfico. La especificación inicial mínima explica por qué el RFC ofrecía piezas combinables sin imponer un algoritmo universal. Las capas de realidad conservan por separado deterioro, alarma, decisión, paquete y resultado.

La lección no es acumular rutas de respaldo. Es impedir que el inventario se convierta en prueba. Una recuperación exige saber quién vio el fallo, quién lo declaró, a quién llegó el aviso, quién movió el tráfico, qué capacidad existía, dónde reaparecieron los paquetes, qué calidad sobrevivió y cuándo volvió a existir protección para el siguiente golpe.

Fuentes