Resumen

  • RFC 3423 reservó al transporte la prueba de entrega de paquetes y respuesta del extremo; el DATA ACK de CRANE solo alcanzaba el último registro en secuencia que el servidor había procesado y puesto en almacenamiento persistente.
  • Una secuencia podía repartirse entre servidores redundantes y producir duplicados. DSN, bit Duplicate, versión de plantilla y reconciliación posterior eran recibos distintos, no sinónimos de una cuenta correcta.

El instante que el ACK de red no veía

El paquete cruza la red. El receptor confirma. En la máquina remota, el proceso todavía tiene que interpretar el registro, escribirlo y asegurar que esa escritura forma parte de una secuencia continua. Si cae antes, la entrega fue real y la conservación no.

Ese intervalo ocupa el centro de RFC 3423, publicado en noviembre de 2002 como especificación Informational de XACCT para Common Reliable Accounting for Network Element. El texto, la ficha del RFC Editor, la página del Datatracker, el historial, las referencias y la consulta de erratas muestran lo que fue: un protocolo empresarial documentado para exportar gran volumen desde elementos de red hacia mediación, BSS y OSS. No fue un estándar de Internet ni es una estadística de uso actual.

Dos capas respondían preguntas distintas

CRANE debía viajar sobre un transporte fiable, orientado a conexión y ordenado. Podía usar TCP o el SCTP histórico de RFC 2960; el memo prefería SCTP por cualidades como orientación a mensajes y detección rápida de fallos. Esa preferencia documental no prueba qué se instaló.

El ACK del transporte permitía descubrir pérdida de paquetes o un servidor que dejaba de responder. El ACK del protocolo CRANE llegaba después del procesamiento y de que la información contable fuese colocada en almacenamiento persistente. La primera señal pertenecía al canal; la segunda, a la aplicación y a su estado durable.

RFC 2975 había expuesto el marco general de la gestión contable: almacenamiento no volátil, pérdida, retransmisión y duplicados. RFC 3423 dio a una parte de ese marco un mensaje operativo. Un enlace sano ya no bastaba para declarar sano el libro de registros.

El mayor número visto no era el mayor número seguro

Cada DATA llevaba un Data Sequence Number. Al arrancar o cambiar de servidor, el cliente fijaba el comienzo con el bit S de sincronización. Los nuevos mensajes incrementaban el DSN uno a uno. El servidor aceptaba lo que llegaba en secuencia y descartaba lo que se adelantaba.

DATA ACK informaba el último DSN correctamente procesado dentro del tramo continuo. Si el servidor veía 3123 mientras faltaba 3122, no podía fingir que 3123 cerraba la brecha. Respondía con su frontera vigente para provocar la retransmisión.

La precisión del número evita otra exageración. Procesado y persistido no significa valorado, facturado o cobrado. Tampoco garantiza que un fallo posterior jamás destruya el soporte. El ACK era la declaración acotada de un receptor en un momento y una sesión.

El recorrido podía saltar de servidor

Una sesión admitía varios servidores con prioridades. El cliente elegía el operativo de mayor prioridad que percibía. Si todos parecían caídos, retenía los registros localmente hasta recuperar uno o agotar la cola; el desbordamiento debía producir una alarma.

La transición podía responder a un puerto sin respuesta, demasiados bytes no confirmados durante un tiempo configurado, un STOP del servidor activo o el regreso de un receptor preferido. El protocolo daba señales, pero no dictaba el algoritmo exacto de cambio.

El ejemplo del RFC reparte una misma historia: servidor 1 recibe 3042–3095, servidor 2 recibe 3096–3122 y servidor 1 continúa desde 3123. El requisito de totalidad pertenece al cliente y al sistema de mediación, no a la memoria individual de un servidor.

Al retransmitir hacia otro receptor, CRANE marcaba el bit Duplicate. El sistema final usaba DSN para eliminar copias. El bit avisaba de una posibilidad; no certificaba la existencia de dos registros ni la ejecución correcta del borrado. Disponibilidad y unicidad podían moverse en direcciones opuestas.

La plantilla decidía qué significaban los bytes

CRANE ahorraba descriptores enviando primero plantillas. Una plantilla ordenaba claves, tipos y significados; cada clave podía activarse o desactivarse. Todos los servidores de la sesión tenían que compartir conjunto y estado.

Cada registro incluía Template ID y Configuration ID. El receptor podía conservar versiones antiguas para interpretar mensajes demorados. No debía recibir una configuración futura antes de tiempo y convenía no cambiar la plantilla hasta confirmar los DATA de la anterior.

La negociación evitaba un ping-pong sin fin. Un servidor proponía cambios una sola vez; el cliente decidía la versión final; FINAL TMPL DATA obligaba a los receptores a aceptarla sin otra modificación. La regla revelaba el control: los servidores asesoraban, el cliente cerraba la semántica común.

Por eso un bloque puede quedar perfectamente persistido y, aun así, ser ilegible o mal interpretado si se pierde el recibo de configuración.

Comparaciones sin fabricar una genealogía

El propio texto contrastaba su objetivo con RADIUS y Diameter. RFC 2865 documenta acceso RADIUS; RFC 2866, su contabilidad. Diameter fue publicado en RFC 3588 y actualizado por RFC 6733. RFC 3334 sitúa requisitos para contabilidad basada en políticas.

El posterior IPFIX ofrece contexto sobre exportación, modelo de información y consideraciones de implementación. Son respuestas distintas a presiones parecidas. Citarlas no demuestra adopción, descendencia directa ni interoperabilidad con CRANE.

Los términos MUST y SHOULD remiten a RFC 2119. Esas mayúsculas obligan al diseño descrito; no son telemetría de un binario.

Un acuse no añadía confidencialidad

La sección de seguridad admitía que CRANE no proporcionaba por sí mismo confidencialidad e integridad fuertes. Aprovisionar direcciones de clientes y servidores era una forma estática de organizar confianza, vulnerable a suplantación sin protección adicional. El documento recomendaba servicios inferiores como IPsec o TLS según el entorno.

Así, DATA ACK no autenticaba automáticamente al emisor, no probaba integridad extremo a extremo y no autorizaba una operación financiera. La identidad del par y la protección del canal merecían comprobantes separados.

Método y límites

La lectura aplica los ensayos de Heng Lu sobre capas de realidad y código en ejecución: norma, código, configuración, almacenamiento y resultado comercial no ocupan la misma capa.

Las fuentes permiten reconstruir el contrato de 2002. No permiten afirmar uso presente, rendimiento medido, incidente conocido, producto vivo o cumplimiento de una instalación concreta. Ese límite protege la historia de convertirse en publicidad retroactiva.