Resumen

  • RFC 2214 añadió a la MIB una fila por interfaz con el backlog C, el retardo D, la holgura y RowStatus; los cuatro objetos eran read-create.
  • La fila describía errores de implementación y una decisión local sobre recursos. No acreditaba que un flujo concreto hubiera atravesado la interfaz, conservado su reserva o cumplido un retardo medido.

En una pantalla de gestión, cuatro valores pueden parecer una promesa completa. Hay bytes, microsegundos, un margen disponible y un estado válido. La interfaz tiene nombre. La fila admite escritura. El salto mental resulta fácil: si el equipo expone esos números, entonces el servicio está garantizado.

RFC 2214 fue más preciso. Publicado en septiembre de 1997 por Fred Baker, John Krawczyk y Arun Sastry, definió la extensión de la MIB de Integrated Services para Guaranteed Service. La garantía cuantitativa pertenecía a RFC 2212. La extensión administrativa mostraba los parámetros locales que permitían describir una implementación real.

C no era una lectura de la cola

El objeto intSrvGuaranteedIfBacklog representaba C en bytes. El texto lo definía como el backlog producido por las peculiaridades con las que una implementación se apartaba de un servicio estricto bit a bit. Para weighted fair queueing por paquetes, sugería la longitud máxima de paquete.

En RFC 2212, C era el error dependiente de la tasa. Al calcular la cota, C se dividía por la tasa reservada R. De ese modo se podía representar un coste cuya duración cambiaba con la velocidad, como la serialización de un datagrama.

La unidad de bytes puede engañar. El objeto no era un contador instantáneo de ocupación. No respondía cuántos bytes esperaban cuando llegó la consulta SNMP. Declaraba qué término de error debía entrar en el modelo. Una cola observada y un error caracterizado pueden compartir unidad sin compartir significado.

D no era un cronómetro de paquetes

intSrvGuaranteedIfDelay expresaba D en microsegundos. D era el error por elemento que no dependía de la tasa: la peor variación de tránsito que el término C no explicaba. RFC 2214 daba como ejemplos el recorrido interno desde una interfaz de entrada hasta el procesador y luego a la salida, o el peor retardo por colisiones en Ethernet.

Este valor podía fijarse en el arranque o por configuración. Para construir la cota de extremo a extremo, los C y D locales debían sumarse como Ctot y Dtot a lo largo del camino. RFC 2212 dejaba esa recolección a un protocolo de establecimiento, al encaminamiento o a funciones de gestión.

Además, la garantía tenía condiciones: el tráfico debía mantenerse conforme, no debía fallar un componente y la ruta no debía cambiar durante la vida del flujo. La cota controlaba el máximo retardo de cola, no el mínimo ni el promedio; la latencia del camino aún debía añadirse. Una fila de interfaz no demostraba ninguna de esas premisas.

La holgura recordaba una decisión

El tercer objeto hacía visible una operación diferente. Si un elemento usaba una cantidad Si de holgura para reducir los recursos reservados al flujo i, tenía que guardar Si. Cuando llegaban refreshs posteriores para ese flujo, debía reutilizar exactamente la misma cantidad sin recalcularla. La regla buscaba consistencia.

La holgura total podía escribirse como S = Dreq - (b/r + Ctot/r + Dtot). Un elemento intermedio podía consumir s <= S. Un scheduler RCSD aumentaba su cota local de retardo; uno WFQ podía disminuir la tasa reservada siguiendo las reglas de transformación. La operación cambiaba margen temporal por una reserva local menor sin aumentar la cota global prevista.

Por eso la holgura no era ancho de banda sobrante ni latencia medida. Era un presupuesto y, sobre todo, el registro de cómo se había gastado. Si cada refresh volvía a decidir, la misma solicitud podría terminar con compromisos distintos. Guardar Si estabilizaba la asignación.

La tabla, sin embargo, estaba indexada por interfaz. No conservaba por sí sola la identidad completa del flujo ni el historial de refreshs. RFC 2213 cubría la tabla genérica de flujos; RFC 2205 cubría el estado blando de RSVP. La prueba de consistencia exigía enlazar esas capas.

read-create señalaba poder, no resultado

Los cuatro objetos podían ser read-create. La sección de seguridad reconocía la consecuencia: un SET de SNMP podía producir una reserva de RSVP o Integrated Services bajo reglas distintas de una negociación RSVP.

Un SET aceptado no equivalía a consentimiento del receptor. Tampoco probaba que el estado blando siguiera vivo, que admission control hubiera aprobado al solicitante correcto, que el clasificador reconociera los paquetes o que el scheduler cumpliera el tratamiento previsto.

RowStatus tampoco cerraba la cadena. En RFC 2214, el estado era válido en interfaces configuradas para Guaranteed Service. La convención general define active como una fila conceptual disponible para el dispositivo gestionado. Es una afirmación local sobre la fila, no un veredicto sobre el camino.

La contribución duradera de RFC 2214 consistió en separar lo que antes podía quedar oculto. C y D mostraban el precio de abandonar el modelo fluido. La holgura mostraba una decisión local de recursos y obligaba a mantenerla durante los refreshs. El estado hacía gestionable la fila. Ninguno convertía la descripción en el hecho descrito.

Fuentes