Resumen

  • RFC 3317 pedía al dispositivo DiffServ que anunciara funciones, límites de profundidad y conexiones permitidas antes de que el servidor de políticas construyera el recorrido del paquete.
  • El anuncio solo orientaba la construcción: si el grafo completo seguía siendo irrealizable, el dispositivo debía devolver un fallo, y ni aceptar ni almacenar la política demostraba el servicio obtenido.

El límite decisivo podía caber en una flecha. El router admitía clasificadores, medidores, colas y planificadores, pero su arquitectura interna no permitía necesariamente conectarlos de la forma elegida por el servidor. RFC 3317 convirtió esa restricción en información que el dispositivo debía exponer.

El documento, publicado como Informativo en 2003, definió una Policy Information Base para controlar recursos de la arquitectura Differentiated Services. El tratamiento de un paquete se representaba con elementos funcionales: primero clasificación, después medición, acciones, descarte algorítmico, cola y planificación. Cuando una política requería repetir una etapa que rompía esa secuencia, se encadenaba otro bloque de acondicionamiento. Los atributos Next marcaban el paso siguiente y formaban un grafo dirigido.

No todo estaba embebido en el mismo objeto. La topología de la cadena se separaba de su parametrización. Un medidor podía apuntar a una instancia con tasa, ráfaga e intervalo; una cola o un planificador podía referirse a parámetros mínimos y máximos. Así era posible reutilizar valores y añadir nuevos tipos en otras PIB. Pero esa flexibilidad no aseguraba que una combinación de objetos válidos cupiera en un equipo concreto.

Por eso la primera carga informativa iba del Policy Enforcement Point al Policy Decision Point. El PEP comunicaba qué clases de aprovisionamiento entendía, qué tipos de interfaz y combinaciones de roles reconocía y qué capacidades estaban disponibles en entrada, salida o ambas direcciones. Solo después el PDP preparaba una política específica para ese dominio y ese tipo de interfaz.

El catálogo describía qué campos podía examinar un clasificador, qué destinos admitía un paquete fuera de perfil, qué algoritmos de descarte existían, cuántas colas y cuánto búfer ofrecía la interfaz, qué métodos y número de entradas soportaba el planificador y cuántos niveles de tasa máxima podía representar. Esa información impedía muchos errores obvios antes de enviar la configuración.

RFC 3317 también modeló errores menos obvios. Una capacidad indicaba el máximo de elementos funcionales consecutivos. Otra enumeraba qué tipo de elemento podía seguir a cuál. El router podía permitir cuatro colas y dos métodos de planificación, pero no aceptar una quinta etapa en la cadena o un enlace directo entre un medidor y cierto planificador. Los límites del grafo estaban en los nodos, en las aristas y en la profundidad.

Una fila de dsDataPathTable elegía el primer elemento según conjunto de capacidades, combinación de roles y sentido del tráfico. La ausencia de esa fila o un inicio zeroDotZero significaba que el dispositivo debía continuar con su procesamiento IP normal. La política se dirigía a tipos de interfaz, no a cada puerto individual, lo que facilitaba la reutilización pero dejaba fuera particularidades físicas.

El propio RFC negó que su declaración fuese completa. Las clases de capacidad proporcionaban pautas generales y no podían listar todas las configuraciones posibles o imposibles. Dos límites válidos por separado podían competir por un recurso compartido. Un encadenamiento admisible podía no caber junto con los demás. Cuando el PEP recibía una política que no podía implementar, debía comunicar el fallo al PDP mediante el mecanismo de COPS-PR.

Esa obligación conserva la jerarquía de evidencia. El anuncio de capacidad es una afirmación general del dispositivo. El grafo compilado es la intención del controlador. La respuesta de aprovisionamiento es un recibo de una transacción. La presencia de filas es estado almacenado. Para demostrar que los paquetes siguieron el tratamiento previsto hace falta observación del plano de datos; para demostrar calidad de servicio hace falta además medir el efecto relevante para el usuario.

Las dos direcciones contenían información valiosa. Las filas instalables podían revelar contratos de clientes o filtros de tráfico y su alteración podía cambiar la asignación DiffServ. Las filas de notificación revelaban características del equipo. RFC 3317 remitía a IPsec entre PDP y PEP: un inventario falso podía inducir un grafo erróneo y una política falsa podía redistribuir ancho de banda y prioridad.

En 2016, el IESG trasladó RFC 3317, RFC 3318, COPS-PR y SPPI a la categoría Histórica. La justificación habló de despliegue limitado y de una gestión de red ya centrada en NETCONF y YANG. La arquitectura concreta perdió continuidad normativa; el problema que intentaba resolver siguió presente en cualquier sistema que traduzca intención a dispositivos heterogéneos.

La lección no es que un inventario de capacidades garantice automatización. Es lo contrario: la declaración acota el espacio de búsqueda, y el rechazo final reconoce todo lo que el modelo no supo expresar. Un control responsable necesita ambos. Si conserva solo el inventario, confundirá posibilidad local con grafo realizable; si conserva solo el fallo, descubrirá demasiado tarde los límites que el dispositivo ya podía haber anunciado.

Fuentes: RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475 y el cambio de estado del IESG de 2016.