Summary

  • RFC 3654 did not prescribe that a Forwarding Element must always keep forwarding or always stop when its Control Element association was lost. It required the architecture to detect loss, restore the association, resynchronize state and preset the FE's response.
  • RFC 7121 later described distinct recovery modes: one returns to pre-association, while another can try backup CEs and may keep forwarding until a timeout. Reconnection still does not prove that every FE state has been restored.

A router can be one system and more than one role

In November 2003, RFC 3654 described a network element as cooperating control and forwarding components that could appear to the outside as one integrated IP device. A Control Element (CE) ran control functions such as routing and signaling protocols. A Forwarding Element (FE) handled per-packet work. The separation was logical; the RFC did not require two chassis or claim that a deployed router had adopted this architecture. Its stated case was that common mechanisms could improve scalability and let the two planes evolve independently. RFC 3654

That division creates an awkward interval. The FE may still have tables and programmed functions, while the CE that manages them is no longer associated. “The controller failed” does not tell us whether the FE stopped forwarding, continued on its current state, or was attempting to reach a backup. RFC 3654 made those separate questions visible.

The requirement specified a decision, not its answer

Architectural requirement 7 bundled four obligations: detect loss of association, restore it, resynchronize state efficiently, and preset what the FE should do while its CE is absent. The document gives continuing to forward and halting operations as examples of that last choice; it does not choose one for every network element. Protocol requirement 8 repeats the same boundary. RFC 3654

This is more than a link-monitoring detail. A forwarding decision made without a currently associated CE may preserve traffic while leaving policy state unchanged; stopping may avoid forwarding on state that cannot be updated but interrupts service. Those are consequences an operator or system designer must evaluate, not outcomes the RFC says were observed. The requirement asks an architecture to make the action knowable before the outage rather than letting an implementation's silence decide it accidentally.

Later high-availability rules put the choice on a clock

RFC 5810, published as a Standards Track protocol specification in 2010, supplied the ForCES protocol and transport mapping that RFC 3654 had required. RFC 5812 defined a model for FE capabilities, state, configuration and logical functional blocks. The three are different: what an FE can do, what it is doing now, and what a CE wants it to do are not interchangeable records. RFC 5810 RFC 5812

In 2014, RFC 7121 added an intra-network-element high-availability procedure. Its FE Protocol Object identifies a master CE and backup CEs; heartbeat intervals and policy help detect connectivity problems. In the default mode 0, loss of association sends the FE back to pre-association; if it later associates, its FE state must be recreated. Mode 1 uses restart recovery: the FE tries configured backup CEs in round-robin order while a CE Failover Timeout Interval runs. During the not-associated state it may continue forwarding, depending on the configured CE-failover policy. If the interval expires without association, the FE enters pre-association and brings down its forwarding path. RFC 7121

Re-association is not the same as state recovery. RFC 7121 says the CE may try to synchronize state the FE lost during disconnection, but leaves the synchronization method outside the ForCES architecture; it notes that new configuration messages and queries would typically be involved. The protocol therefore distinguishes a surviving data path, a reachable backup and a reconciled FE state.

A heartbeat is an input, not a verdict on the route

RFC 3654's reliability requirement treats payloads differently. Configuration, forwarding-table and capability information must be delivered robustly. A heartbeat used to detect a lost association may prioritize timeliness over strict reliability. That makes sense for a detector, but it means heartbeat delivery and forwarding correctness are different evidence. A missed signal can contribute to an association-state transition; it does not by itself prove physical failure, bad routes or total device loss. RFC 3654

RFC 3532, another ForCES document, addressed dynamic partitioning and resource changes that could leave a controller's model behind the forwarding element. That is a neighboring problem, not this one: this article follows the preset FE action and high-availability recovery after association loss, not resource reallocation or stale inventory. RFC 3532 RFC 3746

These documents record architecture and protocol requirements, not a named vendor, deployment, outage or adoption rate. RFC 3654 is Informational; later Standards Track specifications show how the work was elaborated, not that any particular network used it. Router-level forwarding duties remain a separate context supplied by RFC 1812. RFC 1812 RFC 3654 record RFC 3654 Datatracker

Sources