Resumen

  • RFC 9938 reúne las funciones de control y gestión que permiten crear, modificar y borrar flujos DetNet, calcular caminos factibles, reservar recursos e instalar comportamiento por salto. El cálculo solo puede llamar «óptimo» a un resultado después de recibir una jerarquía autorizada de latencia, pérdida, variación, ancho de banda, protección, riesgo compartido y convivencia.
  • La pieza que falta es un recibo de titularidad de restricciones: enlaza la solicitud y sus objetivos versionados con quien puede resolver los compromisos, el presupuesto aceptado por cada dominio, la evidencia usada por el cálculo, las condiciones de revisión, la caducidad de excepciones y el responsable de liberar recursos, sin convertir la auditoría en un mapa sensible de la red.

Dos caminos correctos y una pregunta que la topología no responde

El controlador encuentra dos caminos válidos. El primero ofrece el menor retardo con una sola reserva. El segundo usa dos trayectos separados y funciones de replicación para soportar un fallo, pero consume capacidad y búferes en ambos. Los dos cumplen el formato de la solicitud. Los dos pueden instalarse. Ningún enlace del mapa dice cuál debe ganar.

La elección depende de algo que no es topología: la misión del servicio y la autoridad para comprometer recursos comunes. ¿Es la continuidad una obligación dura o una preferencia? ¿La latencia máxima admite una degradación temporal? ¿El flujo puede ocupar el corredor de protección que otro servicio espera utilizar? ¿Qué mínimo se ha prometido al tráfico no determinista?

El algoritmo necesita respuestas para puntuar las opciones. Si las recibe, puede trabajar con exactitud. Pero la exactitud del cálculo no explica quién estaba legitimado para proporcionarlas. En esa diferencia se encuentra la gobernanza de la ruta.

RFC 9938 resulta útil porque muestra el punto de separación sin pretender cerrarlo. Publicado en marzo de 2026 como RFC Informational del IETF, ofrece un marco para el plano controlador de Deterministic Networking. Recopila requisitos y describe posibles arquitecturas; no especifica todavía el protocolo de una solución completa.

La prudencia del documento evita atribuirle una promesa que no hace. El problema aparece cuando una implementación toma una interfaz técnica como prueba suficiente del mandato institucional.

El plano controlador reúne funciones, no necesariamente responsables

En DetNet, el término Controller Plane agrupa lo que en otros contextos se divide entre plano de control y plano de gestión. El primero instancia y mantiene flujos, distribuye información, reserva y configura. El segundo observa rendimiento, conectividad y fallos, además de apoyar la configuración y la administración.

RFC 9938 enumera una superficie amplia: creación, modificación y eliminación dinámica de flujos; cálculo de rutas explícitas; reserva de ancho de banda, procesamiento y memoria; disciplina de colas; agregación; asignación de etiquetas; replicación, eliminación y ordenación; descubrimiento de capacidades; adaptación a cambios; y verificación del servicio.

Agrupar esas funciones ayuda a razonar sobre la arquitectura. No implica que una sola organización sea propietaria de todas las decisiones. La aplicación conoce el propósito. El responsable del servicio conoce la promesa. El operador de dominio conoce el coste local. El controlador sabe transformar los datos disponibles en configuración. El equipo de seguridad protege la identidad del controlador. El equipo de operaciones interpreta las mediciones.

Si todos se esconden tras una cuenta técnica, una instrucción puede ser auténtica y, aun así, carecer de la aprobación particular que requiere.

La solicitud puede llegar desde una aplicación mediante una API, desde aprovisionamiento estático, desde un controlador SDN o desde señalización distribuida. Esos son canales válidos para transportar intención. No son, por sí mismos, una jerarquía de prioridades.

Una cifra en el modelo no revela su condición

RFC 9016 ofrece un modelo de información de flujo y servicio. Una aplicación puede expresar ancho de banda, límite de retraso, tolerancia a pérdidas y otras necesidades. RFC 9938 destaca que la especificación de tráfico describe el peor caso, no el promedio. Eso permite reservar para una carga exigente.

Pero un valor no llega con su historia. Un límite de diez unidades puede proceder de una propiedad física, de un contrato, de una observación antigua o de una plantilla conservadora. El mismo número puede ser obligación, preferencia o alarma. Tratarlo siempre como duro puede excluir alternativas sanas. Tratarlo siempre como blando puede vaciar la garantía.

También importa quién puede cambiarlo. El propietario de una aplicación quizá pueda pedir menos latencia, pero no duplicar sin límite la capacidad reservada. Un operador local puede ofrecer una ruta alternativa, pero no redefinir el significado extremo a extremo de la protección. Un sistema automático puede ajustar un peso durante una incidencia, pero solo durante la ventana y el alcance que alguien aprobó.

YANG puede representar el estado. NETCONF puede enviarlo. Una arquitectura PCE puede calcular y controlar de forma central. BGP-LS puede aportar datos de topología. La corrección de esas operaciones no convierte el valor inicial en una decisión autorizada.

La cadena debe conservar el origen normativo de la restricción, no solo su codificación.

Reservar es distribuir escasez

RFC 8938 explica que el plano de reenvío DetNet utiliza rutas explícitas y asignación de recursos. Reservar puede reducir contención, pérdida y variación para un flujo. El documento señala que la mejor ruta depende de la característica elegida: mayor ancho de banda, menor jitter o varias métricas; no tiene por qué ser la más corta.

Por tanto, el problema no consiste en encontrar una propiedad llamada «óptimo» escondida en la red. Consiste en decidir qué propiedad debe optimizarse en esta ocasión.

La protección lo hace visible. Packet Replication, Elimination and Ordering Functions puede mantener el servicio enviando copias por caminos distintos. Esa redundancia compra resiliencia con recursos. Cada copia ocupa oportunidades de transmisión, procesamiento y, a veces, búfer. En un entorno finito, proteger más a un flujo puede dejar menos margen a otro.

RFC 8655 evita imaginar una isla exclusiva. Una red DetNet debe convivir con tráfico no-DetNet y evitar su inanición. Incluso cuando se reserva una proporción elevada, el programador debe dejar oportunidades suficientes para los demás usuarios. Enviar un flujo determinista a un dominio no aprovisionado para soportarlo se considera una falta; el aprovisionamiento puede incluir la decisión administrativa de que existe capacidad aguas abajo.

Ese detalle convierte la selección en una decisión distributiva. Un camino puede cumplir la SLA del solicitante y, no obstante, infringir el piso que la institución asignó a otra población. El cálculo necesita ver ese piso como restricción. La auditoría necesita ver quién lo fijó y quién podía autorizar una excepción.

La arquitectura cambia la forma del rastro

RFC 9938 describe tres configuraciones generales. En una distribuida, los nodos y protocolos de señalización propagan información y establecen la reserva. En una centralizada, el controlador reúne capacidades, calcula candidatos, selecciona y configura. En una híbrida, la computación central convive con señalización distribuida como RSVP-TE.

Cada opción produce evidencia en lugares distintos.

En el diseño distribuido, una suma de admisiones locales puede crear un servicio extremo a extremo. Ningún nodo tiene que conocer todo el propósito, lo que protege la compartimentación. Pero la reconstrucción posterior debe unir la petición inicial, las versiones y las respuestas sin inventar un decisor central que nunca existió.

En el diseño centralizado, el controlador ofrece un punto lógico donde correlacionar datos, cálculo y orden. Esa comodidad puede hacer que su credencial se vuelva una autoridad universal. Sin un alcance explícito, resulta difícil distinguir la capacidad técnica de configurar una red del derecho a preferir un servicio frente a otro.

En el híbrido, un cálculo correcto puede llegar a una señalización que observa un estado posterior. La disponibilidad cambia, un nodo aplica una política local o la reserva se ajusta. Si solo se guardan dos mensajes de éxito, se pierde la posible diferencia entre la versión calculada y la admitida.

No hay una arquitectura que resuelva automáticamente la titularidad. Hay arquitecturas que obligan a componerla de manera diferente.

Un servicio multidominio es una cadena de promesas limitadas

Para varios dominios, RFC 9938 prevé que distintas Controller Plane Functions colaboren para convertir la solicitud del Flow Management Entity en comportamiento por flujo y por salto. Pueden descubrirse, autenticarse y negociar. El plano de aplicación puede repartir parte de las responsabilidades.

Autenticar al otro controlador es imprescindible. Demuestra una relación con una identidad técnica. No dice cuánto puede pedir esa identidad, para qué clase de servicio, durante qué tiempo ni bajo qué regla de retirada. Negociar un comportamiento local tampoco demuestra que todos compartan idéntica definición de medición, protección o degradación.

Una prueba de extremo a extremo no debería exigir que cada dominio entregue su topología completa. Bastan compromisos componibles. El dominio puede atestiguar el subconjunto de restricciones aceptado, la clase de recurso, el intervalo, la activación, la condición de revaluación y la liberación. Una huella permite enlazar el compromiso con la solicitud global.

Así se preserva la autonomía sin confundir opacidad con ausencia de responsabilidad. Si un compromiso caduca, el servicio global sabe que debe volver a decidir. Si la ruta interna cambia dentro del contrato local, no es necesario revelar cada detalle. Si el cambio rompe una propiedad extrema a extremo, el enlace impide que el éxito local oculte la ruptura.

La pregunta útil no es «¿confío en este controlador?» en abstracto. Es «¿qué compromiso verificable está autorizado a asumir ahora?»

La seguridad no sustituye el alcance del mandato

RFC 9055 analiza manipulación e inyección de mensajes, elección de rutas, controladores comprometidos y agotamiento de recursos. Un atacante puede hacer que los nodos crean que reciben órdenes autorizadas. La suplantación del plano controlador podría cambiar ancho de banda, extremos o flujos. Retrasar una retirada puede retener capacidad e impedir nuevas asignaciones.

La respuesta técnica requiere autenticación, integridad y diseño resistente. Sin esos controles, ninguna gobernanza puede confiar en la evidencia.

Pero existe otro caso: el mensaje es auténtico, el controlador está sano y la orden es válida, aunque rebasa su delegación. Tal vez el servicio solicitó más capacidad de la permitida; la excepción expiró; se añadió un dominio no aprobado; o un modo de protección temporal se volvió permanente. Ni la firma ni la ruta calculada detectan por sí solas esa desviación.

Clasificarla como intrusión conduce a la reparación equivocada. Rotar claves no restaura la versión correcta del objetivo. Clasificarla como error algorítmico tampoco ayuda si el algoritmo hizo exactamente lo pedido. Hace falta una prueba que compare el acto con la autoridad particular.

Al mismo tiempo, esa prueba debe ser discreta. RFC 9055 advierte que observar números de flujos, bandas y calendarios puede revelar intención. Un registro exhaustivo de rutas y horarios sería un premio para el reconocimiento. La auditoría puede trabajar con huellas, intervalos, clases de recurso y resultados sin publicar el mapa operativo.

La observación decide cuándo deja de valer la elección

El plano de gestión debe comprobar rendimiento y conectividad. RFC 9938 diferencia pruebas activas, que inyectan tráfico y pueden alterar retraso y caudal, de observación pasiva, preferida en operación. RFC 9551 detalla el marco OAM.

Por eso una métrica necesita método y fecha. Una prueba activa realizada durante la puesta en marcha no representa necesariamente el martes siguiente. Una medida pasiva promedio puede ocultar una cola de incumplimientos máximos. Una vista de topología puede ser coherente y estar demasiado atrasada para una decisión crítica.

El sistema debe unir la restricción con la evidencia que la alimenta: ventana, frescura, agregación, incertidumbre y responsable. La pérdida de disyunción entre rutas, la expiración de un compromiso de dominio, el fracaso de una retirada o una modificación repetida son motivos para reabrir la decisión.

La supervisión no existe solo para demostrar después que el SLA se cumplió. Señala cuándo el mandato calculado ha dejado de corresponder al estado real.

El ámbito exacto de la prueba matemática

Con una instantánea definida, un conjunto de restricciones y una versión de algoritmo, el controlador puede demostrar que evaluó candidatos, descartó algunos y ordenó otros. La instalación puede demostrar que los nodos recibieron el estado. OAM puede demostrar el comportamiento observado durante un periodo.

Ese conjunto no prueba automáticamente:

  • que la solicitud proviniera del propietario del objetivo;
  • que las restricciones fueran la versión vigente;
  • que la dureza de cada condición estuviera bien clasificada;
  • que el consumo respetara el techo aprobado;
  • que la replicación mereciera su coste;
  • que se mantuviera la convivencia con tráfico ordinario;
  • que todos los dominios asumieran el mismo significado;
  • que una degradación tuviera vencimiento y corrección;
  • que la reserva terminara con la autoridad que la creó.

Pedir al cálculo que pruebe esos hechos no lo fortalece. Oculta el lugar donde deberían producirse.

Un recibo de titularidad de restricciones

El recibo propuesto empieza con una huella de la solicitud, el rol del solicitante, el dueño del servicio, la frontera del Flow Management Entity y el intervalo. No necesita copiar el propósito industrial ni los datos del flujo.

Después enumera las restricciones versionadas con su procedencia y condición: dura, blanda o de vigilancia. Distingue pico reservado de promedio observado, límite contractual de objetivo de ingeniería, protección obligatoria de preferencia. Incluye el piso de convivencia y el presupuesto máximo.

La autoridad aparece de forma explícita: quién puede ponderar condiciones blandas, aceptar un modo degradado, comprometer otro dominio, superar un umbral y ordenar la retirada. La identidad de administrador del controlador no reemplaza este alcance.

La evidencia del cálculo puede ser compacta: huella y frescura de la instantánea, versión del evaluador, huella del conjunto candidato, huella de la ruta elegida, razones de descarte e incertidumbre. Cada dominio añade su token limitado de compromiso.

El final registra activación, ventana OAM, detonantes de revisión, caducidad de excepción, retorno, responsable de liberar y correcciones. Si el mundo cambia, se emite un recibo sucesor enlazado. No se reescribe el anterior como si hubiera conocido el futuro.

Límites de la evidencia

Los RFC no documentan un incidente de una red concreta, ni prueban que un producto haya reservado mal, que un operador haya incumplido o que exista escasez general. RFC 9938 es un marco Informational, no una solución completa ni una obligación de usar el recibo propuesto.

La inferencia editorial es más estrecha. Cuanto más precisa sea la automatización, más importante es conservar la decisión que definió sus objetivos. El camino puede ser óptimo respecto a sus entradas y, a la vez, carecer de una respuesta recuperable sobre quién podía escoger esas entradas.

Calcular, autenticar, instalar y medir siguen siendo necesarios. La gobernanza empieza antes: determinar qué significa óptimo, a quién protege y qué recursos está autorizado a gastar.

Fuentes

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9938/
  5. https://www.rfc-editor.org/rfc/rfc9938.html
  6. https://www.rfc-editor.org/rfc/rfc8655.html
  7. https://www.rfc-editor.org/rfc/rfc8938.html
  8. https://www.rfc-editor.org/rfc/rfc9016.html
  9. https://www.rfc-editor.org/rfc/rfc9055.html
  10. https://www.rfc-editor.org/rfc/rfc9551.html
  11. https://www.rfc-editor.org/rfc/rfc9633.html
  12. https://www.rfc-editor.org/rfc/rfc7426.html
  13. https://www.rfc-editor.org/rfc/rfc8283.html
  14. https://www.rfc-editor.org/rfc/rfc9552.html