Resumen

  • La RFC 3477 permitió que RSVP-TE indicara enlaces punto a punto sin numerar mediante la pareja formada por un Router ID estable y un Interface ID de alcance local.
  • Los extremos podían escoger cifras sin relación entre sí; la intención del ERO, la resolución de IF_ID, el registro RRO y la realidad del reenvío seguían siendo comprobantes distintos.

Llamar “sin numerar” a un enlace puede sugerir que carece de identidad. En la RFC 3477 ocurría algo más interesante: el enlace tenía dos nombres válidos, uno visto desde cada extremo, pero ninguno podía separarse del equipo que lo había creado.

Cada LSR asignaba un número de 32 bits distinto de cero y solo debía garantizar su unicidad dentro de su propio ámbito. La norma decía expresamente que no había una relación previa entre los valores elegidos en ambos extremos. Para A, su cifra era local y la de B remota; para B, las categorías se invertían. El punto de vista no era contexto decorativo, sino parte del significado.

La forma útil del nombre era, por tanto, una pareja. El Interface ID viajaba junto al Router ID del LSR que lo había asignado. Este último debía ser una dirección estable, normalmente de loopback, que siguiera siendo alcanzable mientras existiera alguna conectividad con el equipo. Así, dos routers podían reutilizar la misma cifra sin colisionar y un solo enlace podía portar dos cifras diferentes sin contradicción.

El diseño respetaba la autoridad local en lugar de fabricar un registro universal. El valor de 32 bits era barato y administrable dentro de un nodo. El Router ID aportaba el alcance necesario para usarlo fuera. Quitar esa referencia convierte una identidad precisa en un dato ambiguo; fusionar los dos extremos borra quién tomó cada decisión.

Los vecinos tenían que compartir sus asignaciones. La RFC admitía configuración, LMP, RSVP o CR-LDP en el caso de una forwarding adjacency, además de extensiones de IS-IS u OSPF. Cuando el IGP participaba en ingeniería de tráfico, sus módulos y RSVP dentro del LSR debían coincidir. La pareja de campos no podía compensar una tabla de vecinos desactualizada.

El Explicit Route Object era el primer lugar donde operaba el nuevo nombre. Su subobjeto Unnumbered Interface ID tenía tipo 4, longitud 12 y llevaba Router ID e Interface ID. Dentro de un ERO expresaba qué enlace no numerado debía usarse para construir la ruta. Era una orden o restricción del trayecto previsto, no un certificado de que los datos ya lo habían recorrido.

Después venía la resolución entre vecinos. Si el siguiente salto salía por un enlace sin numerar, el nodo enviaba un IF_ID RSVP_HOP con su Router ID y el identificador local que había asignado. El receptor comparaba esa pareja con su conocimiento de los números elegidos por los vecinos. Si no encontraba coincidencia, debía considerar una respuesta IF_ID ERROR_SPEC con código 24 y valor 16, “Unknown Interface Index”.

El error demuestra una falta de resolución concreta en un receptor y un momento determinados. No prueba por sí solo que la fibra no exista, que el emisor sea malicioso, que todo el IGP esté equivocado o que no haya otra ruta. Para atribuir la causa hacen falta el origen de la correspondencia, su versión, la dirección del mensaje y el estado de las adyacencias.

El Record Route Object reutilizaba el tipo 4 y la longitud 12, pero con otra función. El ERO describía intención; el RRO acumulaba el rastro que RSVP había registrado al avanzar el mensaje Path. Compartir formato no convertía un deseo en una observación ni una observación del plano de control en telemetría física.

Dos bits del RRO evitaban otra simplificación. Uno indicaba protección local disponible; el otro, protección local en uso, normalmente porque una reparación mantenía el túnel tras una caída. La capacidad de reaccionar y la reacción activa eran hechos distintos. Si el sistema solo guarda “protegido”, pierde el cambio de estado que explica un incidente.

La misma lógica cubría forwarding adjacencies sin numerar. El extremo de cabecera y el de cola asignaban sus propios identificadores, y el objeto LSP_TUNNEL_INTERFACE_ID, clase 193 y C-Type 1, podía portar el nombre directo en Path y el inverso en Resv. Aunque el “enlace” fuera un LSP convertido en recurso de ingeniería, seguía teniendo dos perspectivas administrativas.

Los documentos posteriores de GMPLS, OSPF, IS-IS y agrupación de enlaces extendieron o anunciaron estos identificadores. La RFC 6107 actualizó más adelante la RFC 3477 para Path Key. Son fuentes de genealogía técnica, no evidencia de que una red concreta de enero de 2003 desplegara todas esas funciones.

La separación de capas defendida en las notas de Heng Lu impide exagerar cada registro. El Router ID da alcance al nombre, pero no prueba alcance operativo actual. El ERO expresa intención, no tránsito. El RRO registra estado RSVP, no continuidad óptica independiente. Una etiqueta asignada no confirma que el hardware esté programado, y un puerto programado no confirma entrega de tráfico.

Una auditoría seria conserva el mensaje RSVP original, la sesión, el remitente, la dirección y el tiempo. Guarda el orden de ERO, la pareja IF_ID, la fuente del mapa vecino, el resultado de la búsqueda, los estados Path y Resv, la operación de etiquetas, el orden de RRO y sus bits. Solo después lo une con inventario, adyacencia, tabla de reenvío, alarmas y contadores, cada uno con procedencia propia.

Nunca debe almacenarse el Interface ID como si fuera un pequeño número global. Tampoco debe “limpiarse” la disparidad de los extremos imponiendo una cifra canónica. Esa disparidad documenta quién tenía capacidad para nombrar en cada lado del enlace.

La aportación histórica de la RFC 3477 fue hacer compatible la pluralidad sin eliminarla. Una infraestructura distribuida no necesitaba un nombre único para cada unión. Necesitaba llevar el alcance, conservar ambas miradas y distinguir lo pedido, lo resuelto, lo registrado y lo realmente operativo. El enlace no numerado tenía identidad; simplemente no pertenecía a una sola voz.

Fuentes