Software-Defined Network Forwarder Context Sharing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional OpenFlow forwarders suffer from redundancy in information storage and maintenance, leading to inefficiencies in packet processing due to direct associations between flows and actions, which complicates action changes and hinders complex processing capabilities.
Innovation Solution
The method involves a forwarder that processes packets by determining the flow and context identifiers, using a correspondence between flows and context identifier sets, and a correspondence between context identifiers and contexts, allowing for context-based processing without direct association of flows with contexts, enabling efficient storage and processing of multiple flows sharing contexts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If flows are directly associated with actions in the flow table, then packet forwarding can be implemented, but redundancy occurs in information storage and maintenance becomes difficult
Solution Approach 1:
The patent segments the flow table entry into two separate components: flow information (matching criteria) and context information (processing actions). Instead of directly associating actions with each flow, the patent introduces an intermediate context layer that multiple flows can share. This segmentation eliminates redundancy by allowing multiple flows to reference the same context information without duplicating it in each flow table entry.
Solution Approach 2:
The patent introduces context information as an intermediary between flows and actions. Rather than directly linking flow matching criteria to processing actions, the system uses context identifiers as mediators. Flows are associated with context identifiers, and contexts contain the actual action information. This intermediary structure enables efficient sharing of common processing logic across multiple flows.
2Adaptability or versatility
If actions are changed for multiple flows, then packet processing can be updated, but all related flow table entries need to be changed which is very difficult
Solution Approach 1:
By separating flow-specific matching criteria from context-specific processing actions, the patent enables independent updates. When an action needs to be changed, only the context information needs to be modified, not every flow table entry that references that context. This segmentation makes maintenance straightforward and efficient.
Solution Approach 2:
The context information structure is designed to be universal and reusable across multiple flows. A single context can serve multiple flows, and when that context is updated, all flows that reference it automatically benefit from the update. This multi-functionality eliminates the need to update each flow individually.
3Adaptability or versatility
If a large quantity of flow table entries are stored to handle complex packet processing, then processing capability is improved, but storage space and processing overhead increase
Solution Approach 1:
The patent merges common processing logic into shared context information that can be referenced by multiple flows. Instead of duplicating action information in each flow table entry, the system consolidates redundant context data into a single location. This merging significantly reduces storage space while maintaining the ability to handle complex packet processing scenarios.
Solution Approach 2:
Context information is designed as a universal resource that can be shared across multiple flows. A single context can handle various packet processing tasks for different flows, eliminating the need to create separate flow table entries for each processing scenario. This universality reduces both storage requirements and processing overhead.
Data Source
Figure 1~2
Figure 3
Figure 4~5
AI summary
Embodiments of the present invention provide a method for processing a packet in a software-defined network (Software-Defined Network), where the method is performed by a forwarder, and the method includes: receiving an input packet; determining a flow to which the input packet belongs according to the input packet; determining a context identifier set corresponding to the flow to which the input packet belongs according to a first correspondence between flows and context identifier sets, where a context identifier set corresponding to each flow in the first correspondence includes at least one context identifier; determining a context corresponding to the context identifier set according to a second correspondence between context identifiers and contexts; and processing the input packet according to the context corresponding to the context identifier set. In the embodiments of the present invention, a flow is not directly associated with a context, and even when multiple flows share a context, this context does not need to be saved for multiple times, and under a hardware condition the same as that in the conventional technology, a storage capability and a processing capability of a forwarder are greatly improved in the embodiments of the present invention.