Resumen

  • RFC 9938 es un marco informativo de la IETF: compila conceptos, requisitos y arquitecturas posibles para un plano de controlador DetNet, y reserva los detalles de protocolo para documentos posteriores.
  • El hecho de que un controlador reciba una solicitud o envíe configuración no basta para demostrar admisión en cada salto, reservas vigentes, PREOF funcionando, métricas dentro del límite ni resultado de negocio.

El comité recibió una demostración impecable. El controlador leía la topología, conocía capacidades, aceptaba una solicitud por API y proponía un camino explícito. En la consola, los nodos aparecían configurados. La frase final fue fácil: «ya tenemos servicio determinista».

Lo que tenían era una parte valiosa de una cadena, no el final de la cadena.

RFC 9938, publicado en marzo de 2026, se titula A Framework for the Deterministic Networking (DetNet) Controller Plane. Es Informational. Su resumen dice que presenta conceptos y requisitos que podrían ser base de una futura especificación de solución. La introducción es aún más directa: el documento no aporta los detalles de protocolo de una solución para el plano de controlador; esos detalles pertenecen a trabajos posteriores.

Una organización madura debe leer esa precisión como una ventaja. El RFC hace visible qué debe ocurrir antes de que pueda sostenerse una promesa: aprender estado, calcular, reservar, instalar, coordinar y observar. No autoriza a convertir el diagrama de esa secuencia en una certificación de que terminó.

Centralizar no elimina los hechos locales

El RFC presenta tres arquitecturas: plano distribuido con señalización dinámica, plano totalmente centralizado similar a SDN y plano híbrido. En el ejemplo centralizado, un controlador obtiene topología y capacidades DetNet, recibe una petición de establecimiento y configura nodos mediante NETCONF/YANG, DetNet YANG o un controlador basado en PCE. El enfoque distribuido propaga información por protocolos; el híbrido reparte el trabajo entre ambos.

Son modelos posibles, no una única arquitectura impuesta. De hecho, RFC 9938 dice que las extensiones necesarias para varias combinaciones híbridas son trabajo futuro.

La diferencia evita errores de gobierno. Una petición por API es evidencia de intención entregada. Un cálculo es evidencia de una decisión algorítmica con determinada topología y política. Un commit de configuración es evidencia de una operación de gestión. Pero ninguna de esas piezas dice por sí misma que cada nodo aceptó y mantuvo recursos, que una cola concreta se aplicó al tráfico definido, que la protección se formó o que la aplicación recibió su resultado dentro de la condición contratada.

PREOF y reserva no son casillas de verificación

RFC 9938 pide soporte para creación, modificación y eliminación dinámica de flujos. Entre las funciones posibles están determinación de rutas explícitas, reserva de ancho de banda, buffers y otros recursos, disciplinas de cola, manejo bidireccional y agregación. También trata PREOF: replicación, eliminación y ordenamiento de paquetes.

Es precisamente una lista de hechos que deben tener sus propias pruebas. La reserva propuesta no acredita una reserva admitida. La reserva admitida no acredita que sobreviva a un cambio de política, topología o dominio. La configuración de un dispositivo no acredita el comportamiento de los paquetes seleccionados. Una colección de segmentos no acredita que PREOF opere correctamente para el flujo y época reclamados.

En varios dominios, la cautela crece. El RFC prevé que las funciones de plano de controlador habrían de colaborar y que controladores de dominios distintos podrían descubrirse, autenticarse y negociar comportamiento por salto. La frontera operativa no desaparece porque una consola la dibuje con una sola línea.

Conservar una cadena de recibos verificables

El recibo de la solicitud debe fijar servicio, solicitante autorizado, extremos, dirección, clase, perfil de tráfico y límite requerido. El de decisión debe guardar la versión de topología, capacidades consideradas, algoritmo, regla y ruta candidata. El de admisión debe asociar cada salto con el recurso, cola, etiqueta o encapsulación, rol de protección y vigencia efectivamente confirmados. El de observación debe nombrar población de tráfico, dirección, método, reloj y ventana. El recibo final debe provenir del límite en el que el cliente o proceso soporta la consecuencia.

Esta disciplina no exige que el RFC prometa más de lo que promete. Sigue la Primacía del Código en Ejecución de Heng Lu: una vista central, un modelo o una intención no deben desplazar el estado verificable en sistemas operativos. También evita que una capa de realidad —la de planificación— absorba las capas de instalación, medición y resultado.

Sources