OpenFlow Controller Proactive Flow Entry Registration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In OpenFlow networks, the proactive type of flow table entry registration is desirable for reducing hardware processing frequency and preventing unauthorized access, but it is challenging to implement due to the potential for a large number of entries, and existing methods rely mainly on the reactive type.
Innovation Solution
A network system where a controller registers entries in switches with unique path identifiers based on physical topology before communication starts, allowing switches to operate on pre-defined rules and actions, thereby enabling proactive type registration and improving hardware performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If proactive type flow table entry registration is implemented, then hardware processing frequency is reduced and unauthorized access is prevented, but the number of entries becomes huge making implementation challenging
Solution Approach 1:
The controller performs preliminary actions by calculating paths and registering flow table entries before actual data communication begins. The controller proactively determines routing paths based on destination addresses and registers corresponding entries in switch flow tables in advance, eliminating the need for reactive processing during data communication and preventing unauthorized access before it occurs.
Solution Approach 2:
The flow table entries are segmented into different types: unicast entries for specific destination addresses and multicast entries for broadcast/multicast addresses. This segmentation allows the system to manage the large number of potential entries by organizing them into manageable categories, where unicast entries are registered proactively for known destinations while multicast entries handle group communications efficiently.
2Productivity
If proactive type flow table entry registration is implemented, then hardware processing frequency is reduced, but the complexity of calculating and managing path identifiers increases
Solution Approach 1:
The controller performs preliminary path calculation and entry registration before data communication starts. By calculating paths in advance based on destination addresses and network topology, the system eliminates the need for real-time path calculation during data communication, significantly reducing hardware processing frequency while managing the complexity through pre-computation.
Solution Approach 2:
The controller acts as an intermediary that performs complex path calculation and entry registration tasks centrally, before data communication begins. This intermediary approach transfers the computational complexity from hardware processing during data communication to a centralized controller that performs calculations in advance, reducing the processing burden on hardware during actual data transmission.
3Device complexity
If reactive type flow table entry registration is used, then the number of entries is suppressed, but hardware processing frequency increases and performance deteriorates
Solution Approach 1:
The system performs preliminary actions by registering flow table entries in advance before data communication begins. The controller calculates paths and registers entries proactively, so that when data communication starts, the hardware can process packets using pre-configured entries without frequent hardware intervention, reducing processing frequency while maintaining manageable entry numbers through intelligent registration timing.
Data Source
AI summary
A network system includes a communication apparatus, and a control apparatus configured to control the communication apparatus. The communication apparatus includes a memory configured to store program instructions, and a processor configured to execute the instructions to receive an address of a destination virtual machine from the control apparatus, receive a packet from a source virtual machine, identify, based on the address of the destination virtual machine corresponding to the received packet, an identifier of an edge node connected to the destination virtual machine, and add the identifier of the edge node to the received packet.