Summary

  • RFC 2124 let an external Flow Admission Service allow, reject, redirect or constrain a connection while the switch remained the place where connectivity actually began.
  • The protocol carried separate receipts for admission, execution errors, live state, counters and later policy changes; each receipt proved one handoff, not the whole service result.
  • AMBIGUOUS, NO_SUCH_FLOW and the complete absence of security analysis show why policy authority, device action, state agreement and economic records must remain separate.

In March 1997, the authors of RFC 2124 described a practical shortcut around a problem that had not yet been standardized. An ATM switch could ask an external Flow Admission Service, or FAS, whether a proposed connection should proceed. The FAS could allow it, reject it, attach operating policy or redirect it. Network managers gained one place to express admission decisions across several switches without forcing every vendor to implement every policy language.

The RFC Editor record and IETF Datatracker record keep the status clear: this was an Informational memo, not an Internet Standard. The historical value lies elsewhere. LFAP drew a line through a distributed decision system and gave each side enough messages to expose where its knowledge stopped.

The switch asked because the switch originated the connection

All initiating exchanges began at the switch. Its Connection Control Entity, or CCE, sent a Flow Admission Request just before setting up a flow. The FAR could carry the source and destination, service identifier, client data, switch addresses, a flow identifier and the switch’s time of request.

The FAS replied with a Flow Admission Acknowledge. An FAA could include optional policy, mandatory policy, a redirect destination or a failure code. That response was a policy verdict about a described flow. It was not a packet trace, a completed circuit or proof that the switch had executed the answer.

RFC 2124 made that distinction observable. An unsupported optional policy could be ignored. An unsupported mandatory policy could not. The CCE had to abort the flow and return a Flow Admission Update reporting the failure. Central policy therefore remained conditional on local capability. The FAS decided what must be true; the switch discovered whether it could make it true.

This is the first receipt boundary. A FAR proved that one CCE asked about one proposed flow. An FAA SUCCESS proved that the FAS accepted that request under the information it received. Only the later device state could show what the switch actually established.

A running flow produced another evidence stream

Once a connection existed, the CCE sent Flow Update Notifications. A FUN could report the switch time, active or inactive state, bytes and packets, cells or frames sent and received. Notifications could be periodic, triggered by a state change or requested by the FAS.

The counter type mattered. A running counter covered the interval since establishment; a delta counter covered only the period since the previous FUN. Combining the two without preserving their type could manufacture a total that no component had asserted. Even a correct counter said nothing by itself about who was entitled to the flow, whether the traffic reached an application or whether a bill was valid.

The Flow Update Acknowledge sharpened the handoff. RFC 2124 says that SUCCESS meant the information in the corresponding FUN had been accepted and had become the responsibility of the FAS. That is a custody statement about information. It is not a retroactive guarantee that the switch’s counter was complete, the FAS stored it durably, alternative instances agreed or a customer received service.

Policy could change after admission

The architecture was not limited to a one-time gate. A FAS could send a Flow Change Request to add or replace operating policy or set the flow inactive. The switch replied with a Flow Change Acknowledge. Stopping a flow was expected to make the CCE send final statistics and report the inactive state.

Again, the acknowledgement was bounded. An FCA could report POLICY_REJECT when the switch did not support the requested change, or NO_SUCH_FLOW when the switch had no state for the identifier. The original permission did not make later control automatic. A policy system had to keep reconciling its model with the device that held the connection.

The error codes are the most honest part of the design

AMBIGUOUS protected flow identity from convenient reuse. If a duplicate Flow ID arrived with a FAR identical in every respect except possibly Message ID, the FAS replayed its earlier answer. If the content differed, it refused to guess and required a new identifier. Idempotence belonged to the whole request, not to the label alone.

NO_SUCH_FLOW exposed two directions of state loss. A FAS could receive a FUN for a connection it had never admitted or no longer remembered. A switch could receive an FCR for a flow it no longer knew. The remedy was not to treat either database as metaphysically correct; it was to re-admit, report or stop the connection according to the observed mismatch.

Flow prefixes addressed failover. A FAS could assign a prefix and the CCE could append its own identifier, producing an identity intended to remain globally unique across alternative services. If the CCE did not support the prefix, failover could make one call appear as two at the accumulation point. The namespace reduced collision risk. It did not prove that two FAS instances had identical state.

Centralization solved translation, not trust

LFAP’s appeal was credible: policy representation was not standardized, so the interface spared switches from understanding every organizational policy system. Yet that economy created a powerful external control point. A redirect could change the destination. A mandatory policy could determine whether setup survived. An FCR could stop a live flow. The protocol never specified how the FAS authenticated its authority, how a switch authorized those actions or how accounting evidence should be protected.

The entire Security Considerations section says that security issues are not discussed. That omission matters more than any modern retrofitting. A TCP connection to the FAS was transport, not proof of legitimate policy origin. A registered service name was coordination, not deployment assurance; the current IANA registry lists csi-lfap on port 3145 and separately warns of known unauthorized use of that port.

The contrast with BTW’s existing coverage is precise. RFC 2063 provides the broader traffic-measurement architecture and the published BTW analysis focuses on the time gap left by asynchronous reading. RFC 2123 records NeTraMet implementation experience and the published analysis focuses on how a rule set projected traffic into selected rows. RFC 2124 owns a different boundary: a central policy answer and the switch state that followed it were never the same receipt.

Three Heng Lu essays help state the durable discipline. Running-Code Primacy gives operational reality priority over institutional declaration. Minimum Initial Specification, Localized Future Decision argues that common rules should remain narrow and locally verifiable. On Reality Layers warns against confusing an administrative representation with executable reality.

LFAP anticipated programmable admission before modern policy controllers had their current names. Its most useful legacy is not the belief that central decisions are inherently efficient. It is the evidence chain showing why the decision, execution, reconciliation and economic record must be audited separately.

Sources