Resumen

  • RFC 2213 expuso por SNMPv2 la capacidad reservable de cada interfaz y una fila por flujo con selectores, tasa, ráfaga, metadatos de cola, policing, descarte y RowStatus.
  • Cada dato tenía un límite propio: el índice no era un valor de protocolo, el owner era una clase de proceso, los contadores tenían un epoch de instalación y un SET podía crear reservas fuera de la negociación RSVP.

intSrvFlowPoliced contaba paquetes sometidos a policing desde el inicio del servicio del flujo. La descripción de la fila añadía la precisión decisiva: el contador empezaba al instalar el flujo. Esa frase impide convertir el número en una historia completa.

Si una fila se elimina y reaparece, nace otro periodo de medición. Un cero puede indicar que no hubo infracciones, que no llegó tráfico coincidente o que la instalación es reciente. Un valor creciente demuestra que el agente incrementó ese objeto bajo sus reglas; no identifica al solicitante, no certifica todos los paquetes y no acredita entrega.

Una MIB para ver y, a veces, escribir

Fred Baker, John Krawczyk y Arun Sastry publicaron RFC 2213 en septiembre de 1997. La MIB tenía una tabla de atributos de interfaz —bits y buffers asignados, máximos, número de flujos, retraso adicional y estado— y una tabla de flujos reservados activos.

Cada fila de flujo reunía tipo de sesión, owner instalador, direcciones y máscaras, protocolo y puertos, interfaz, tasa, ráfaga, peso, cola, tamaños mínimo y máximo, contadores, política de descarte, servicio QoS, orden de clasificación y estado. Muchos campos eran read-create, aunque la conformidad permitía implementarlos solo en lectura. El modelo describía una superficie de control posible, no una capacidad universal.

intSrvFlowNewIndex coordinaba la creación con TestAndIncr. El gestor leía un candidato, lo devolvía en el SET y repetía tras inconsistentValue. El número resultante servía exclusivamente para indexación SNMP. Pese al nombre SessionNumber, RFC 2213 declaraba que no tenía relación con ningún valor de protocolo. Localizar una fila no equivale a identificar una sesión RSVP.

El instalador no era el titular

intSrvFlowOwner distinguía other, rsvp y management. Indicaba qué proceso había instalado el flujo en la base de política de colas. No era un nombre personal, una organización, una credencial ni una autorización. Un owner rsvp tampoco conservaba el mensaje original, los datos de política, la decisión de admisión o la continuidad del soft state.

RFC 2205 separaba RSVP, routing y traffic control. El routing elegía el camino; RSVP transportaba y mantenía parámetros; un clasificador seleccionaba paquetes; admission control evaluaba recursos; un scheduler decidía su transmisión. La fila de gestión proyectaba parte de esa maquinaria en un nodo. No la sustituía.

Las direcciones, máscaras, protocolo, puertos e interfaz describían el selector local. Algunos valores no podían cambiar con la fila activa. Esa inmovilidad protegía una configuración, pero no demostraba que un paquete hubiera coincidido ni que otros saltos mantuvieran una reserva compatible.

La cola tenía un dialecto local

La tasa reservada se derivaba del Tspec en Controlled-Load o del Rspec en Guaranteed Service. La ráfaga expresaba el máximo esperado, aunque el pacing adicional quedaba a opción de la red. MinTU y MaxTU definían el tratamiento de policing, no una medición del tráfico observado.

Peso y número de cola eran explícitamente específicos de la implementación. El mismo entero podía significar políticas distintas en dos equipos. No probaba algoritmo, contención, latencia ni trato real. Era una perilla o referencia local.

El contador best-effort registraba paquetes degradados; el contador policed registraba acciones desde el epoch de la fila. intSrvFlowDiscard decidía si el tráfico marcado se perdía o pasaba a best effort, siendo este último el valor por defecto. Una política configurada no es evidencia de que un paquete concreto la atravesó.

Active no era un recibo del camino

intSrvFlowStatus aparecía active para flujos activos y podía instalar, borrar o autorizar clasificación estática. RowStatus describía la disponibilidad de una fila para el dispositivo. No guardaba el camino causal de identidad, consentimiento y resultado.

La sección de seguridad fijó una frontera poco cómoda: un SNMP SET podía producir una reserva RSVP o Integrated Services bajo reglas diferentes de las usadas por una negociación RSVP. Por eso, un SET exitoso no prueba consentimiento del receptor. Una fila active tampoco prueba refreshs, autorización, hits del clasificador, comportamiento del scheduler ni servicio a lo largo de la ruta.

Incluso RFC 2205 trataba una confirmación RSVP como una indicación de alta probabilidad, no como garantía hasta los emisores. La fila local de RFC 2213 era más estrecha. Su valor histórico fue hacer visible el plano de gestión sin declarar que ese plano contenía toda la realidad.

Fuentes