Resumen
- RFC 9914 define la proyección DAO: una raíz RPL, o un controlador externo mediante la raíz, puede instalar rutas proyectadas que no tienen que seguir el DODAG principal.
- Un PCE puede calcular rutas usando la topología y restricciones como longitud, batería y búferes reservables; después la raíz proyecta el resultado en el dominio RPL.
- La especificación contempla P-Routes en modo Storing y Non-Storing, situaciones híbridas, acuse, mantenimiento, expiración, sustitución y eliminación.
- No afirma que toda ruta proyectada sea más corta o más segura. El cambio central es que el estado instalado y su ciclo de vida pasan a ser parte crítica de la operación.
RFC 9914 es un estándar propuesto del IETF, publicado en abril de 2026. Actualiza RFC 6550, RFC 6553 y RFC 8138. La arquitectura base de RPL sigue siendo el DODAG: se espera que la instancia RPL principal exista previamente en modo Non-Storing, mientras que las rutas proyectadas pueden generar situaciones híbridas. En Storing, el estado proyectado se instala en los nodos correspondientes; en Non-Storing, la representación de encaminamiento de origen y el estado proyectado siguen las reglas de la especificación. Hay que probar la interacción entre modos, no asumir que uno elimina al otro.
El cambio operativo está en la responsabilidad del plano de control. Un PCE puede calcular un trayecto direccional aplicando políticas y restricciones, no solo contando saltos. La raíz señaliza un DAO proyectado hacia participantes concretos. Los nodos confirman la instalación cuando corresponde, mantienen el estado y procesan su renovación, expiración, sustitución o eliminación. Una RIB separada con mayor precedencia puede hacer que el estado proyectado gane frente a alternativas normales.
Eso sirve para un atajo punto a punto, una ruta de protección o una ruta intercalada en un Track de 6TiSCH, pero también puede hacer que un estado obsoleto siga mandando hasta que se retire o expire.
Esto es encaminamiento de origen de RPL y procesamiento de opciones RPL, dentro de los límites de RFC 6553 y con la compresión descrita por RFC 8138 cuando resulte aplicable; no es SRv6. Tampoco es una optimización universal. Según las restricciones, una ruta puede ser más larga, menos resistente o más costosa, y una instalación parcial puede no coincidir con el grafo completo que conoce el PCE. Por eso la decisión debe basarse en la garantía del estado, no únicamente en la calidad del cálculo.
Fuentes
- RFC 9914: Root-Initiated Routing State in RPL
- RFC 6550: RPL
- RFC 6553: RPL Option for Carrying RPL Information
- RFC 8138: RPL Routing Header Compression
- RFC 9030: 6TiSCH Architecture
- RFC 9912: RAW Architecture
- RFC 9450: RAW Use Cases
Registro de evidencia de afirmaciones
| Afirmación | Evidencia RFC |
|---|---|
| Proyección DAO y P-Routes | RFC 9914, resumen y secciones 1–6 |
| Base DODAG de RPL | RFC 6550 |
| Señalización de información RPL | RFC 6553 |
| Límite de compresión del encabezado RPL | RFC 8138 |
| Tracks y arquitectura de red restringida | RFC 9030 |
| Grafo de recuperación y cobertura adyacente | RFC 9912 |
| Casos de uso de fiabilidad y baja latencia | RFC 9450 |
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
