Resumen

  • RFC 3936 repartió los números RSVP entre estándares, experimentos y usos privados dentro de tres bandas cuyo comportamiento ante clases desconocidas ya estaba fijado.
  • Un objeto de clase desconocida podía hacer rechazar todo el mensaje, desaparecer él solo o atravesar el nodo intacto; un C-Type desconocido dentro de una clase conocida seguía otra regla.

La envoltura conocida no salvaba al subtipo

Un nodo RSVP podía conocer la clase de un objeto y, sin embargo, no conocer su C-Type. RFC 2205 advertía que intentar una respuesta “inteligente” dependiente de cada clase era complejo y a menudo inútil. En general, el C-Type desconocido hacía rechazar el mensaje.

La clase completamente desconocida seguía otro árbol. El Class-Num 0bbbbbbb exigía rechazar el mensaje y devolver Unknown Object Class. 10bbbbbb hacía ignorar el objeto, sin reenviarlo ni generar error. 11bbbbbb permitía llevarlo sin examinar y sin modificar hasta un nodo capaz de entenderlo. El registro oficial de RFC 2205 acredita el documento; los bits del paquete seleccionaban la acción.

Esa diferencia impidió que RFC 3936 tratara la tabla de números como una simple lista de nombres. Publicada en octubre de 2004 como BCP 96, la norma buscó revisión suficiente para las extensiones sin cerrar el camino experimental.

Cada conducta tenía tres puertas de entrada

RFC 3936 colocó Standards Action, Expert Review y Vendor Private dentro de cada una de las tres bandas. Para las clases que harían rechazar el mensaje, reservó 0–119, 120–123 y 124–127. Para las que harían descartar solo el objeto, 128–183, 184–187 y 188–191. Para las que cruzarían un nodo desconocedor, 192–247, 248–251 y 252–255.

La tabla actual de parámetros RSVP de IANA conserva esa estructura. El eje administrativo responde quién obtiene el número y qué documento necesita. El eje binario responde qué hace el código viejo. Una asignación privada en la última banda seguía teniendo una consecuencia pública: propagación del objeto por nodos que no podían interpretarlo.

La ficha de RFC 3936 muestra que actualiza RFC 2205 y RFC 3209, la extensión RSVP-TE para túneles LSP. Su página de erratas permite comprobar correcciones. La ficha de RFC 3209 establece su historia documental, no la presencia de cada extensión en una red.

La reutilización privada llevaba un identificador público

Los usos Vendor Private no se registraban uno por uno. Para que dos empresas pudieran reutilizar el mismo número sin confundir formatos, el primer bloque de cuatro octetos debía contener su número SMI del registro de Private Enterprise Numbers de IANA.

Ese número separaba espacios; no autenticaba al remitente. Tampoco convertía dos formatos propietarios en interoperables. Si el nodo no reconocía el número empresarial, todavía debía obedecer el Class-Num exterior. El significado podía permanecer cerrado y la reacción de compatibilidad seguir siendo común.

RFC 3936 exigió además que cada nueva clase declarara cómo se asignarían sus futuros C-Types. Para clases anteriores, Standards Action quedaba como política por defecto salvo sustitución mediante RFC Standards Track o BCP. Así evitaba confundir la autoridad sobre una clase con la autoridad sobre todas sus variantes futuras.

Los subobjetos EXPLICIT_ROUTE y RECORD_ROUTE de RSVP-TE recibieron particiones propias y un identificador empresarial para el uso privado. RFC 3473 aporta el contexto de posteriores extensiones GMPLS, y RFC 2207 el de puertos virtuales para flujos IPsec. Ninguno permite trasladar automáticamente el comportamiento de Class-Num a cualquier otro campo numérico.

La autoridad documental también seguía la banda. Cambiar el procesamiento de una entidad Standards Action requería un RFC Standards Track; para una entidad Expert Review, un RFC Experimental. RFC 2434 contenía la guía de asignación contemporánea. RFC 8126 la reemplazó después, sin reescribir el diseño original.

El registro demuestra una asignación, no una implantación. No indica qué software reconoce una clase, qué valores privados circulan ni si un fabricante conservó intacto un objeto 11bbbbbb. Las ideas de Heng Lu sobre especificación mínima y adopción y sobre código en funcionamiento recuerdan que publicación, implementación y uso son evidencias distintas.

La historia de RFC 3936 es, por tanto, la de una gobernanza que tuvo que respetar decisiones ya incrustadas en el cable. El número podía ser privado; la reacción del router desconocedor no lo era.