Stateful Packet Forwarding via Local FSMs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The existing OpenFlow data plane API is limited in its ability to deploy states within forwarding apparatuses, leading to unnecessary centralization of stateful processing and increased signaling load, which can result in processing delays and hinder real-time reconfiguration of network control algorithms.

Innovation Solution

The proposal involves extending the OpenFlow abstraction using Extended Finite State Machines (XFSM) to enable stateful processing directly within network forwarding apparatuses, allowing for the formal specification and execution of states without further interaction with the controller, while maintaining high-speed implementation and vendor-agnostic compatibility.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If stateful processing is centralized in the network controller, then control simplicity is maintained, but processing delays increase and real-time reconfiguration is hindered

Engineering Contradiction:
Improvecontrol simplicityVSAvoidprocessing delays
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The patent segments the control architecture by separating state management from packet forwarding. The network controller retains high-level control while local switches maintain finite state machines (FSMs) for stateful processing. This segmentation allows state transitions to occur locally without controller intervention, eliminating processing delays while preserving centralized control for policy updates.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension of state management by embedding FSMs within the data plane of network switches. This dimensional shift moves stateful processing from the control plane (controller) to the data plane (local switches), enabling parallel state transitions and eliminating the sequential bottleneck of controller-based processing.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If the OpenFlow API is extended with more functionalities, then network programmability is enhanced, but the API complexity increases

Engineering Contradiction:
Improvenetwork programmabilityVSAvoidAPI complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent enables self-service by allowing network switches to autonomously execute state transitions based on local FSMs. Instead of requiring the controller to manage every state change through complex API calls, the switches independently process stateful operations, reducing API complexity while maintaining enhanced programmability through the FSM configuration interface.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent introduces FSMs as an intermediary layer between the OpenFlow API and the packet forwarding logic. This intermediary provides a structured framework for stateful processing that simplifies the API interface while enabling complex network programmability, as the FSM abstraction handles state management details automatically.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Speed

If state transitions are handled locally in switches, then processing speed increases, but controller authority is reduced

Engineering Contradiction:
Improveprocessing speedVSAvoidcontroller authority
Core Design Contradiction:
SpeedVSExtent of automation

Solution Approach 1:

The patent applies preliminary action by pre-configuring FSMs in network switches with all necessary state transition rules before deployment. This allows switches to autonomously execute state transitions at high speed without real-time controller intervention, while the controller maintains authority by updating FSM configurations when network policies change.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms where switches report state information and statistics back to the controller. This feedback loop allows the controller to maintain awareness of network state and adjust FSM configurations accordingly, preserving controller authority while enabling fast local processing.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3117572B1Method of handling data packets through a state transition table and apparatus using the same
Publication Date: 2023.03.29 BIANCHI GIUSEPPE
  • EP3117572B1 patent drawingFigure 1
  • EP3117572B1 patent drawingFigure 2
  • EP3117572B1 patent drawingFigure 3

AI summary

The apparatus (SW) has a plurality of input/output ports (P1, P2, P3, P4, P5) for receiving and transmitting data packets, and comprises a data packets handling circuitry (DPL) arranged to forward data packets between the input/output ports (P1, P2, P3, P4, P5) and an internal apparatus controller (CPL) arranged to control the data packet handling circuitry (DPL); the apparatus (SW) has a control port (PC) for communication between the internal apparatus controller (CPL) and an external network controller (NWC); the apparatus controller (CPL) is arranged to store (MEM) at least one state transition table (TT) to be used for controlling the forwarding of data packets by the data packets handling circuitry (DPL); the apparatus controller (DPL) is arranged to use said at least one state transition table (TT) for implementing at least one finite state machine (FSM); the apparatus controller (DPL) is arranged to use said at least one state transition table (TT) for handling separately distinct incoming data packets flows through corresponding distinct instances of finite state machine; the apparatus controller (DPL) is arranged to receive said at least one state transition table (TT) through the control port (PC).