Resumen

  • RFC 3476 incorporó campos de la UNI óptica del OIF a los espacios públicos de LDP y RSVP, pero remitió su contenido y uso a la especificación del OIF.
  • La diversidad o el nivel de servicio podían no estar disponibles; la conexión podía ser desconocida y el emisor o receptor, no autorizado. Un número válido era apenas el primer comprobante.

Los registros de protocolos gobiernan algo diminuto: nombres y números. Esa modestia es su fuerza. Si dos equipos usan el mismo valor para objetos distintos, la interoperabilidad se rompe antes de que empiece la operación. Si coinciden, pueden entender qué se solicitó. Todavía no saben si deben aceptarlo ni si pueden realizarlo.

RFC 3476 fue publicado en marzo de 2003 como documento Informativo, no como Estándar de Internet. El Optical Internetworking Forum había creado una señalización para la interfaz óptica usuario-red, la UNI. Quería reutilizar LDP, RSVP, RSVP-TE y GMPLS tanto como fuera posible, pero unas necesidades propias exigían identificadores nuevos en espacios administrados por IANA.

En LDP aparecieron tres TLV Source ID y tres Destination ID, con variantes IPv4, IPv6 y NSAP. Se sumaron Egress Label, Local Connection ID, Diversity, Contract ID y UNI Service Level. Los valores asignados estaban entre 0x0960 y 0x0970. En RSVP se creó GENERALIZED_UNI, clase 229 y C-Type 1, además de UNI_IPv4_SESSION, clase 1 y C-Type 11. Sus subobjetos podían transportar direcciones TNA de origen y destino, diversidad, etiqueta de egreso y nivel de servicio.

La aparente exactitud del catálogo escondía una frontera muy deliberada. Para cada TLV, el RFC decía que el contenido y el uso se describían en la especificación UNI del OIF. El registro público resolvía la colisión numérica. El acuerdo externo explicaba la semántica. La red real aún debía autenticar, autorizar, admitir y encontrar recursos.

No era solo una separación de documentos, sino de poder. OIF definía una interfaz orientada al servicio. IETF aportaba protocolos reutilizables. IANA mantenía los espacios de números. El operador controlaba equipos y capacidad. Ninguno de esos papeles absorbía a los demás. Un valor de IANA no convertía el servicio de OIF en norma de la IETF, ni obligaba a una red a aceptarlo.

El borde público y privado también quedó visible. Los códigos de estado UNI de LDP se tomaban del espacio de uso privado 0x3Fxxxxxx y no requerían administración de IANA. Dos mensajes previstos por OIF, Status Enquiry y Status Response, ya estaban obsoletos, por lo que no recibieron código. El registro no fue una fotografía de todas las ideas: fue el resultado de decisiones sobre cuáles merecían identidad pública.

Los errores RSVP revelan el resto de la cadena. La red podía responder “diversidad no disponible”, “nivel de servicio no disponible” o “identificador de conexión inválido o desconocido”. También podía rechazar a un emisor o receptor no autorizado. Ninguna respuesta significaba que el analizador hubiera confundido el número. Significaba que, después de reconocerlo, otra autoridad dijo no.

Un objeto GENERALIZED_UNI puede superar todos los controles de formato. Su clase, C-Type, longitud y subobjetos pueden ser correctos. Las TNA pueden ser válidas. Aun así, el emisor puede carecer de facultad contractual, el receptor puede no consentir, la base de topología puede no ofrecer rutas disjuntas o la capacidad puede estar ocupada. La corrección sintáctica no adelanta esos veredictos.

Un punto de código afirma: “interprete estos bits como este objeto”. No afirma: “obedezca a este actor”, “reserve esta longitud de onda”, “programe este conmutador” o “declare entregado el servicio”. La confusión aparece cuando el primer enunciado toma prestada la autoridad de todos los siguientes.

Los protocolos de base conservaban sus propios límites. RSVP mantenía estado de reserva; RSVP-TE añadía túneles; LDP distribuía etiquetas; GMPLS ampliaba la etiqueta más allá del paquete. Los RFC 3471 a 3475 separaban identidad, mensajes, notificaciones, Calls y Connections. RFC 3476 no atravesó esas capas: añadió el vocabulario numérico para que una petición UNI pudiera circular por ellas.

RFC 3936 describió después políticas para asignaciones RSVP y RFC 8126 refinó la regla general de que la sección de IANA debe instruir al registro, mientras la documentación técnica vive en otra parte. No son prueba de las reglas exactas de 2003. Sí permiten reconocer el oficio administrativo que RFC 3476 ya practicaba: hacer estable una referencia sin fingir que la referencia ejecuta la función.

Los registros actuales de IANA son evidencia de asignación. No son telemetría de la red. No muestran que el cálculo de ruta hallara diversidad, que se reservara capacidad, que una matriz óptica cambiara, que hubiera señal o que el cliente transmitiera tráfico.

La disciplina de capas de realidad de Heng Lu exige conservar la secuencia completa. Primero, el mensaje bruto, el valor y la versión fechada del registro. Después, las revisiones exactas de RFC y OIF y el resultado del analizador. Luego, identidad, autenticación, autorización, admisión, ruta, reserva, programación física, señal, tráfico y resultado comercial. Cada salto necesita su propio comprobante.

Source ID no es poder autenticado. Diversity no es un par de rutas independientes. Service Level no es un SLA cumplido. Egress Label no demuestra un circuito físico. La ausencia de error tampoco sustituye una confirmación positiva de los trabajos posteriores.

También importa preservar el rechazo: objeto, código, subcódigo, nodo, hora y petición correlacionada. “Diversity not available” localiza mejor la decisión que un fallo genérico, pero no certifica toda la topología ni descarta cada alternativa concebible.

Por eso RFC 3476 es una pieza de historia institucional, no solo una tabla de números. Demuestra lo que un registro público hace bien: permitir que extraños nombren lo mismo. También demuestra lo que no puede hacer: autorizar, construir o verificar el servicio. El número abre el expediente; las pruebas operativas deben cerrarlo.

Fuentes