Summary

  • RFC 3423 gave transport and application acknowledgements different jobs: one detected packet loss or an unresponsive receiver; the CRANE DATA ACK advanced only after records had been correctly processed and placed in persistent storage.
  • A durable frontier still was not a final bill. DSN continuity, alternate-server failover, duplicate removal, template version, security and downstream accounting each needed its own receipt.

Two green lights, two different facts

A network element exports a usage record. The reliable transport delivers the bytes, receives an acknowledgement and looks healthy. A few milliseconds later the receiving process fails before committing the record. Which system is right?

Both can be. The transport has proved its proposition: the peer stack received enough data to advance its transport state. The accounting system has not yet proved its different proposition: the record was interpreted, processed and stored durably. RFC 3423, published in November 2002, designed XACCT’s Common Reliable Accounting for Network Element protocol around that gap.

The memo was explicitly Informational, not an Internet Standard. Its plain-text record, IETF document page, history, references and errata search preserve a vendor-originated proposal for moving high-volume accounting data from network elements to mediation, business-support and operations-support systems. They do not establish present deployment.

Transport reliability stopped short of the ledger

CRANE expected a reliable, connection-oriented, in-sequence transport. TCP or SCTP could carry it; the document preferred the historical SCTP of RFC 2960 for message orientation, authentication capability and faster failure detection. It prohibited using UDP as the accounting transport, although an optional version-discovery exchange used UDP for a much narrower purpose.

The architecture then stated the critical distinction. Transport acknowledgements helped detect lost packets and unresponsive servers. CRANE acknowledged messages after they had been processed and the accounting information had been placed in persistent storage.

That second acknowledgement was not ornamental duplication. It moved the evidence boundary from “bytes reached the peer” to “the receiving application claims its durable frontier has advanced.” RFC 2975 had described the broader accounting-management problem, including non-volatile storage and duplicate elimination. CRANE attempted to expose those concerns in a high-volume delivery protocol rather than hiding them behind one generic success lamp.

The DATA ACK named a frontier

Every DATA message carried a Data Sequence Number, or DSN. After startup or a transition to another server, the client marked the first message with the S, or DSN Synchronize, bit. Each newly originated message incremented the DSN by one. The receiver accepted in-sequence records and discarded out-of-sequence arrivals.

The DATA ACK carried the DSN of the last correctly processed in-sequence message. If an out-of-sequence record arrived, the receiver sent its current acknowledgement again, prompting immediate retransmission of what remained unacknowledged.

The number therefore described a contiguous processed frontier, not merely the greatest packet number ever observed. A receiver that had seen 3123 while still missing 3122 could not honestly advance the frontier to 3123. Nor did the frontier say that the record had been rated correctly, attached to the right subscriber, invoiced, settled or retained forever. It was an application-storage receipt with a precise subject.

Reliability could split one sequence across several servers

CRANE allowed a session to include prioritized redundant servers. The client sent records to the highest-priority receiver it perceived as operating. If none was available, it queued records until a receiver returned or local queue space ran out, at which point an alarm was expected.

Server transition was tied to several observations: the transport could report an unresponsive port; unacknowledged bytes could remain above a configured threshold for a configured duration; an active server could send STOP; or a preferred server could recover. The protocol supplied the state and messages, while leaving the transition algorithm to implementation.

Its numerical example is more instructive than the word failover. Server 1 might receive DSNs 3042 through 3095, server 2 receive 3096 through 3122, and server 1 resume at 3123. No single receiver held the entire run. The sender still owed the mediation or billing system a complete sequence.

Retries could also deliver the same logical record more than once. A record resent to another server carried the Duplicate bit, and the downstream system was to use DSN to eliminate duplicates. The bit meant “this may be a repeat”; it did not prove that a twin existed, that it was found, or that deleting one copy was semantically safe.

A record needed a schema receipt too

Efficient delivery removed field descriptors from each record. Instead, a negotiated template described the ordered keys, their types and meanings. Keys could be enabled or disabled, and all servers in one session were supposed to share the same template set and key state.

Each record carried both Template ID and Configuration ID. The pair mattered. An identifier without the applicable configuration could point to the wrong layout; an older configuration might require retained template history; a future configuration arriving early could be misread. The document recommended waiting until DATA under the old configuration had been acknowledged before sending the new template.

Negotiation also had a control boundary. A server got one chance to propose changes. The client chose the final set and sent FINAL TMPL DATA to every server. At that point receivers had to accept and acknowledge it without another amendment, avoiding an endless loop among redundant receivers.

Thus a DATA ACK depended on more than storage media. It depended on session, DSN, server, Template ID, Configuration ID and negotiated key state. A stored byte array under the wrong schema was durable but not necessarily meaningful.

Accounting protocols offered different bargains

CRANE’s introduction compared its goals with RADIUS and Diameter. RFC 2865 defines RADIUS access, while RFC 2866 defines RADIUS accounting. The then-new Diameter work became RFC 3588 and later RFC 6733. RFC 3334 describes policy-based accounting requirements.

Later IPFIX documents—its protocol, information model and implementation guidance—offer another context for templates and exported records. These sources illuminate recurring design pressures. They do not make CRANE a predecessor deployed in the same systems, nor do they license treating unlike acknowledgements as equivalent.

Normative capitals in the memo follow RFC 2119. A MUST describes the specification’s rule. It does not prove a particular binary complied, a queue never overflowed or a storage device survived.

The security receipt remained separate

RFC 3423 said the protocol itself did not provide strong confidentiality or integrity. Static provisioning of client and server addresses could support an operational trust arrangement, but without added protection it remained vulnerable to address spoofing. The memo recommended lower-layer security such as IPsec or TLS when needed.

Consequently, a DATA ACK alone did not prove who sent it, whether a middlebox changed the record, or whether the endpoint was authorized for the session. Transport establishment, peer authentication, message integrity, template agreement, durable processing and business acceptance remain separable facts.

Sources, method and limits

The analysis uses all seven primary RFC 3423 surfaces linked above, the accounting, transport, RADIUS, Diameter, policy-accounting and IPFIX context sources, and Heng Lu’s essays on reality layers and running code as primary. The essays provide the method: do not let a symbolic state absorb what only a lower or later operational layer can establish.

The sources support protocol history and specified semantics. They do not provide a current deployment census, measured performance, a named incident or evidence that a surviving product implements CRANE. A persistent-storage acknowledgement is stronger than a transport ACK for its stated purpose, but it is still bounded by the receiver, configuration, observation time and unobserved later failures.