Resumen

  • RFC 1272 sostuvo que las direcciones IP de los extremos no permitían saber qué dominio administrativo vecino había transportado el tráfico por una frontera.
  • Los medidores fronterizos podían facilitar la conciliación, pero el detalle útil dependía de la topología, la granularidad, el almacenamiento, el coste de recopilación y la seguridad.
  • El memo separó los informes de uso de la facturación y la aplicación de políticas, y dejó sin resolver si contar al entrar o al salir del router.

El nombre que faltaba era el del vecino

Un paquete IP lleva direcciones de origen y destino. Eso permite contar tráfico entre extremos, pero no revela por sí solo qué red vecina introdujo el paquete en el dominio de un proveedor. Si el tráfico de un mismo sistema final puede llegar por distintos dominios adyacentes, conocer ambos extremos no responde a la pregunta más acotada del proveedor: ¿por qué red cruzó mi frontera este tráfico?

RFC 1272 no pretendía que cada red contabilizara el uso de todos los usuarios de Internet. Su modelo se centraba en el dominio de una administración y en los dominios conectados directamente a él. Un proveedor podía medir el tráfico que cruzaba la frontera con un vecino e intercambiar un estado de cuenta. Si ese vecino necesitaba repartir sus propios costes más adelante, era responsabilidad suya. La contabilidad era recursiva: cada administración respondía por la relación que podía observar, sin fingir una perspectiva global del usuario final.

Esto cambia el lugar donde sirve un medidor. Un host observa el tráfico en un extremo. Un router situado en la frontera ve el tráfico que entra o sale del dominio local y aporta evidencia sobre una interconexión adyacente. El memo advertía que las cabeceras IP no incluían por sí mismas la identidad del sistema intermedio; podían hacer falta información de capas inferiores o la configuración de los equipos fronterizos. Las direcciones de los extremos y la frontera contable respondían preguntas distintas.

Medir también tenía un coste

La ubicación era solo una decisión. RFC 1272 describía monitores dedicados, medidores de línea, medidores de software dentro de routers y conjuntos coordinados de «router spiders». El lugar adecuado dependía de la topología y del servicio observado. La frontera podía ayudar a proveedor y cliente a comparar sus registros, pero no era una orden universal de instrumentar cada router.

El memo trataba el detalle como una decisión técnica y económica. Un medidor podía contar por puerto, red o host; añadir atributos de paquetes; guardar contadores o marcas de tiempo; y reportar con distintas frecuencias. Cada combinación de entidad y atributo podía requerir otro registro de flujo. Una granularidad mayor consumía memoria y procesamiento; reportes más frecuentes usaban ancho de banda y capacidad del colector. Si se exigían exactitud y fiabilidad completas, había que examinar todos los paquetes. Para entender comportamiento, ajustar una red o aproximar una cuota de costes, el muestreo podía resultar suficiente y menos costoso.

No son estándares de evidencia equivalentes.

La recopilación también necesitaba protección. Los autores consideraban sensible la información de uso y señalaban la confidencialidad, la integridad y el control de la recogida. Mencionaban acuses con retransmisión, colectores redundantes o almacenamiento de respaldo en el medidor. Un valor tomado en un router no se convierte automáticamente en una cuenta completa y fiable por estar en una frontera.

Un informe no era una factura ni una regla

RFC 1272 limitó expresamente su propósito: ofrecía antecedentes para una arquitectura de informes de uso y no especificaba un estándar de Internet. Los informes podían ayudar a un abonado a entender su comportamiento, a un proveedor a medir el cumplimiento de una política o a distribuir costes. Pero informar no bastaba para imponer una política, y el documento no recomendaba prácticas de facturación. Tampoco resolvía quién debía pagar por la retransmisión de paquetes.

Una cuestión quedó abierta: ¿contar un paquete cuando el router lo recibe o solo cuando lo reenvía? Un router puede descartar paquetes durante la congestión. Contar a la entrada refleja los recursos consumidos por el tráfico ofrecido; contar a la salida evita cobrar tráfico no reenviado. RFC 1272 pidió que la arquitectura permitiera ambas opciones, porque la respuesta dependía de la política y el contexto, no de una verdad técnica universal.

Más tarde, RFC 2722 especificó una arquitectura de medición de flujos. Ese trabajo posterior forma parte de la historia de la medición, pero no prueba que se implantara un modelo de facturación concreto ni toda la visión contable de 1991. La pregunta duradera de RFC 1272 es más limitada: ¿qué puede saber una administración en su frontera y cuánto vale medirlo? Hay que preservar la cadena entre flujo observado, vecino identificado, informe y cualquier decisión posterior de precio o control. Nada de eso se deduce automáticamente de las direcciones IP en los extremos.

Fuentes: RFC 1272; RFC 2722; RFC 2990.