Forwarding and Control Element Separation (ForCES) Forwarding Element Model
updated by
- rfc-7408 — Forwarding and Control Element Separation (ForCES) Model Extension
Extracted elements (30)
LFB data path modeling recommends a hybrid of the topological approach (forking into distinct LFB class paths) and the encoded state approach (metadata-driven parameterization within one LFB type). The topological approach is preferred when paths fork to distinct LFB classes; the encoded state approach reduces graph complexity when N instances of the same LFB class need distinguishable parameterization.
Multiple LFB class inheritance is explicitly prohibited to avoid unnecessary complexity; a single inheritance chain from the base LFB class is required. Inheritance should only be used when there is significant reuse of the base class definition.
Rather than attempting to fully enumerate all FE capabilities in the model, the design combines coarse-level capability reporting with an error-reporting mechanism: if a CE instructs an FE to perform an operation it cannot support, the FE returns an error, analogous to Diffserv PIB approaches.
XML was chosen as the LFB class specification language primarily for human and machine readability, with widely available tooling. The encoding for over-the-wire transport is explicitly decoupled from the specification language and left to the ForCES protocol to define.
For LFB class inheritance backward compatibility, a derived class must be a functional superset of its base class (may only add, not remove, functions). A CE encountering an unknown LFB type MUST query its base class and SHOULD be able to configure the instance to revert to base-class behavior, enabling older CEs to interoperate with FEs running newer LFB class versions.
A single LFB output can be connected to only one LFB input; this is required to make packet flow through the LFB topology unambiguous.
An LFB class specification MUST specify the base class and version number it inherits from (default is the base LFB class); multiple inheritance is not allowed.
An LFB instance on the FE SHOULD support a backward-compatibility mode (reverting to base class behavior), and the CE SHOULD be able to configure the LFB to run in that mode.
FEs MUST NOT support more than one version of a particular LFB class; CEs may support multiple versions for backward compatibility.
For a given metadatum on a given packet path, there MUST be at least one producer LFB that creates that metadatum and SHOULD be at least one consumer LFB that needs it.
For singleton outputs, the LFB class definition MUST include the number of outputs; that count is fixed when the class is defined and cannot be changed at instantiation time or on the fly.
Metadata generation by certain LFBs MUST always precede any use of that metadata by subsequent LFBs in the topology graph; this is required for logically consistent operation.
Modification of packet fields subsequently used as inputs for further processing MUST occur in the order specified in the model for that particular implementation to ensure correctness.
The LFB class namespace MUST be extensible so that new LFB classes can be added later to accommodate future innovation in the forwarding plane.
When a CE encounters an LFB instance of an unknown LFB type, the CE MUST be able to query the base class of that LFB from the FE to enable backward-compatible operation.
When an input port group treats a metadatum as optional, the LFB class definition MUST explicitly define what happens if that optional metadata is not provided (e.g., specifying a default value).
When LFB classes are defined, the input and output packet formats (e.g., IPv4, IPv6, Ethernet) MUST be specified; distinct packet types must be uniquely labeled with a symbolic name and/or ID.
An LFB (Logical Functional Block) class definition formally specifies: number and types of inputs and outputs, metadata consumed and produced per port group, accepted and emitted packet types, packet modifications, routing criteria across multiple outputs, capability components, operational components, and event declarations.
LFB events are declared in the class definition with a 32-bit ID, an event target (LFB component to monitor), a trigger condition (e.g., creation, deletion, config change), and a report payload. CE subscribes at runtime via per-event subscription properties; runtime filters (threshold, hysteresis, time interval) can further suppress events.
LFB input ports support three fan-in models: implicit multiplexing via a single input (multiple outputs connect to it), explicit multiple singleton inputs (distinct stream types, fixed count), and input groups (variable count, where the input index is visible to the LFB for scheduling or table selection).
LFB metadata is per-packet state passed between LFBs as <label, value> pairs; labels carry unique numeric identifiers. Metadata is not transmitted over the network but is conveyed on redirect packets exchanged between FE and CE.
LFB output ports are either singleton outputs (fixed count defined in the class, each with distinct frame and metadata definitions) or output groups (variable count, all instances sharing identical frame and metadata definitions, selectable per packet via an internal mechanism).
The FE Object is a special LFB class of which there is exactly one instance per FE; it provides FE-level capability information (supported LFB classes, LFB topology configurability) and the current LFB topology as components accessible via the ForCES protocol.
A new IANA registry for LFB Class Names and LFB Class Identifiers is established with a 32-bit identifier space. The FE Object LFB class is the first entry. The registration policy uses Expert Review for standard-track classes.
A URN namespace (urn:ietf:params:forces:lfb) is registered with IANA for identifying ForCES LFB class library XML documents and related model artifacts.
The FE model itself does not define security mechanisms; security for CE-FE communication is addressed by the ForCES protocol (RFC 5810). Unauthorized manipulation of LFB components or topology via the ForCES protocol could disrupt or subvert forwarding behavior.
LFB event processing is a four-step pipeline: (1) detect a change to the declared event target and check CE subscription; (2) evaluate the declared condition on the event target; (3) apply runtime event filters (suppress if filtered); (4) submit the declared report to the CE.
The metadata lifecycle within an LFB defines six per-metadatum operations: IGNORE (forward unchanged), READ (read and forward), READ/RE-WRITE (modify and forward), WRITE (create or overwrite and forward), READ-AND-CONSUME (read and terminate lifecycle), CONSUME (terminate without reading). The last two prevent the metadatum from being forwarded to the next LFB.
LFB component paths are expressed as dot-annotated sequences of 32-bit identifiers (e.g., 51.7.89 selects sub-component 89 within row 7 of table component 51). Table elements may alternatively be addressed via key-based content indexing.
The ForCES addressing hierarchy encodes a 32-bit FEID (FE identifier), a 32-bit LFB ClassID (globally unique within the NE, IANA-assignable), a 32-bit LFB instance identifier (unique per class on an FE), and 32-bit component identifiers within an LFB instance.