Hierarchical control software defined network architecture for multi-modal network and data forwarding method

Abstract

The invention relates to the technical field of software-defined network architecture in the technical field of networks, in particular to hierarchical control software-defined network architecture for a multi-modal network and a data forwarding method, the network architecture comprises a centralized controller and a plurality of multi-modal network elements with built-in containerized acquisition controllers, the centralized controller is used for dividing, distributing, arranging and managing multi-mode services, determining ports, queues and flow table resources required by each network mode, and receiving local state information reported by each acquisition controller; and the acquisition controller is deployed in each multi-mode network element, and is used for acquiring a local state of the network element, packaging a state acquisition message, sending the state acquisition message to other network elements through a flooding protocol, constructing a global network view, executing local capacity sensing path calculation based on a distribution result of the centralized controller and the global network view, and programming a strict source route. According to the method, the network convergence speed, the resource utilization rate and the multi-mode service bearing capacity are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of software-defined network architecture and programmable data plane technology in the field of network technology, and particularly to a hierarchical control software-defined network architecture and data forwarding method for multimodal networks, which can be applied to networking scenarios such as wide area networks, data center networks, computing power networks, campus networks and industrial internet in multimodal networks. Background Technology

[0002] The SDN technical architecture comprises a control plane and a data plane. The control plane includes two types: one is the traditional centralized SDN architecture, which relies on a cluster controller outside the data plane, an independent control plane network, and numerous microservices. It requires redundancy and consensus mechanisms to ensure high availability, resulting in millions of lines of code. Furthermore, to cope with controller failures, it retains traditional protocols such as IS-IS and BGP, forming a complex architecture of "new dependencies + old dependencies," leading to frequent failures, long routing convergence times, and significant impact on SLO (Service Level Objective). SLO impact refers to the degree or consequence of the actual service quality deviating from the preset SLO target due to factors such as network architecture design, failures (e.g., link interruptions, controller anomalies), and unreasonable resource allocation. The other type is based on a traditional distributed protocol architecture, employing greedy distributed path calculation, resulting in low network utilization, slow convergence times, and exceeding 10 minutes under extreme failures. The data plane includes the P4 / P4Runtime programmable switching chip system, specifically supporting fixed resource allocation and static entry size configuration for Parser / MAU / Deparser pipelines. Another type of data plane is the ASIC forwarding chip, which has the characteristic of being non-programmable.

[0003] Key problems with existing technologies: The problems with the control plane are: the centralized controller has a complex architecture of "new dependencies + old dependencies", which leads to frequent failures, long routing convergence time and large impact of SLO; the distributed protocol architecture has low network utilization and slow convergence time.

[0004] The problems with the data plane are: the forwarding logic and architecture of traditional ASIC forwarding chips are fixed and the pipeline is rigid, which is not enough to support the changing scenarios; the entries and matching resources of programmable data plane P4 devices are fragmented, and the entry capacity and type (TCAM / SRAM) of each network element are difficult to share across ports or pipelines, resulting in local hotspots and low utilization. The existing SDN network architecture still suffers from the lack of an end-to-end orchestration closed loop. The controller can issue policies, but it lacks a fine-grained segmentation / recycling mechanism and fast timing guarantee for the "table resource pool" inside the network element. Summary of the Invention

[0005] To address the technical challenges of high complexity, frequent failures, slow convergence, and low utilization in the control plane of SDN network architecture, this invention proposes a hierarchical control software-defined network architecture and data forwarding method for multimodal networks. By simplifying the SDN control plane, pooling data plane resources, and optimizing the forwarding mechanism through the hierarchical control architecture, this invention significantly improves network convergence speed, resource utilization, and multimodal service carrying capacity, while reducing SLO impact and fault handling time.

[0006] To achieve the above objectives, the technical solution adopted is: This invention provides a hierarchical control software-defined network architecture for multimodal networks, including a centralized controller and multiple multimodal network elements with built-in containerized acquisition controllers. The centralized controller is connected to each multimodal network element through an out-of-band management channel, and the multimodal network elements achieve state synchronization through a flooding protocol. The centralized controller is used for the division, allocation, orchestration and management of multimodal services, determines the port, queue and flow table resources required for each network mode, and receives local status information reported by each acquisition controller. The acquisition controller is deployed on each multimodal network element to acquire the local status of the network element, encapsulate the status acquisition message and send it to other network elements through the flooding protocol, construct a global network view, perform local capacity-aware path calculation based on the allocation result of the centralized controller and the global network view, and program strict source routing.

[0007] According to the hierarchical control software-defined network architecture for multimodal networks of the present invention, the control plane of the multimodal network element includes an acquisition controller, and the data plane includes a data path processing module, a traffic management module, and a flow table resource pooling module. The data path processing module includes an inlet processing pipeline and an outlet processing pipeline, both of which contain a Parser / Deparser module and an MAU pipeline; The flow management module is located after the inlet processing pipeline and before the outlet processing pipeline, and is responsible for the queue management, copying and scheduling of data packets; The flow table resource pooling module adopts a Buddy-Slab architecture design, which includes a TCAM resource pool and an SRAM resource pool. Flow table data is classified and deployed in the TCAM resource pool and SRAM resource pool according to storage characteristics. Both types of resource pools are connected to the matching unit in the MAU pipeline with high bandwidth and non-blocking through a Crossbar switching architecture.

[0008] According to the hierarchical control software-defined network architecture for multimodal networks of the present invention, the Parser / Deparser module further supports unified reuse of multiple ports and dynamically adjusts the field extraction and encapsulation logic according to the loaded modal configuration.

[0009] According to the hierarchical control software-defined network architecture for multimodal networks of the present invention, the MAU pipeline is further configured as a multi-level structure, and each MAU pipeline includes a matching unit and an execution unit; In the ingress processing pipeline, the matching unit searches the flow table using the network mode identifier address (for IP network modes, the IP address can be used as the identifier address) of the packet header vector as the key to find the corresponding tag stack; the execution unit performs the action of adding a tag stack to the packet based on the matching result; In the outbound processing pipeline, the matching unit searches the flow table using the top-level label in the packet header vector as the key to find the action corresponding to the label; the execution unit executes the action of popping the top-level label and rewriting the destination MAC based on the matching result.

[0010] According to the hierarchical control software-defined network architecture for multimodal networks of the present invention, the traffic management module further supports a programmable scheduling mechanism based on modal tags and interacts with the acquisition controller through the P4Runtime or NETCONF / YANG interface. The traffic management module receives the scheduling policy issued by the acquisition controller. When a data packet arrives, the module parses its modal tag and puts it into the corresponding priority queue according to the mapping rules in the policy.

[0011] According to the hierarchical control software-defined network architecture for multimodal networks of the present invention, both the TCAM resource pool and the SRAM resource pool adopt a Buddy-Slab structure. After receiving the resource allocation instruction issued by the acquisition controller, the resource pool realizes fine-grained resource partitioning through the buddy allocation algorithm.

[0012] Furthermore, the present invention also provides a data forwarding method based on the hierarchical control software-defined network architecture of the above-described multimodal network, comprising: After the multimodal network element is started, the data acquisition controller collects local status information and generates status acquisition messages; The data acquisition controller sends status acquisition messages to other multimodal network elements via a flooding protocol and reports them to the centralized controller via an out-of-band management channel. Each data acquisition controller receives and integrates all status acquisition messages to build a complete and consistent global network view; The centralized controller allocates multimodal service resources based on a global network view; The acquisition controller of the ingress network element performs local capacity-aware path calculation based on the allocation results and the global network view to generate strict source routes; The ingress network element adds a label stack to the data packet through a two-level table lookup. The intermediate network element forwards the data packet according to the label and pops it from the stack. The egress network element completes the final encapsulation of the data packet and sends it.

[0013] According to the data forwarding method of the hierarchical control software-defined network architecture of the multimodal network of the present invention, the two-level table lookup is further described as follows: the first level looks up the egress network element through the network modality identifier address, and the second level looks up the corresponding multimodal label stack through the egress network element.

[0014] According to the data forwarding method of the hierarchical control software-defined network architecture of the multimodal network of the present invention, when a link failure occurs in the network, the acquisition controller of the network element where the faulty link is located immediately activates the local repair path, forwards the data packet to the alternative link, and floods the updated status acquisition message; after receiving the updated status message, the ingress network element recalculates the path to complete the rapid update of the entire network path.

[0015] According to the data forwarding method of the hierarchical control software-defined network architecture of the multimodal network of the present invention, the acquisition controller generates flow table resource allocation instructions based on the multimodal service resource allocation strategy issued by the centralized controller and combined with the locally constructed global network view. The flow table resource pooling module receives the instructions and dynamically divides the TCAM resource pool / SRAM resource pool through the buddy allocation algorithm.

[0016] The beneficial effects achieved by adopting the above technical solution are: 1. Simplified control architecture and accelerated convergence: The traditional centralized controller is reconstructed into a hierarchical architecture of "centralized controller + network element built-in acquisition controller", which unloads some centralized control functions and optimizes the state synchronization mechanism, greatly reducing the complexity of the network architecture and the number of failure points, significantly shortening the propagation time and the overall routing convergence time, and solving the problems of frequent failures and slow convergence in the traditional architecture.

[0017] 2. Enhanced SLO assurance capabilities: Through efficient path calculation under hierarchical control, rapid local fault repair, and refined scheduling of the traffic management module, the number of "bad seconds" is significantly reduced in high-priority traffic scenarios, and the degree of service quality deviation from the SLO target can also be effectively reduced in low-priority traffic scenarios, greatly improving the stability and reliability of network services.

[0018] 3. Improved data plane resource utilization: The TCAM / SRAM hybrid resource pool is constructed using the Buddy-Slab structure. Combined with the Buddy-Slab partner allocation algorithm, it realizes fine-grained resource partitioning and fast recycling, eliminating the fragmentation and local hotspot problems of traditional data plane resources. The utilization rate of table blocks is improved by 20%-60% compared with static slicing (depending on business distribution), achieving high-level and efficient operation of resources.

[0019] 4. Enhanced flexibility and business continuity in data plane reconstruction: Parser / Deparser supports unified reuse of multiple ports, and with the acquisition controller, dynamic monitoring of redundant configuration enables millisecond-level reconstruction. The MAU pipeline can be dynamically plugged in and rearranged by the controller, ensuring seamless or low-jitter operation when adjusting data plane processing logic, and reducing update and maintenance costs.

[0020] 5. Enhanced adaptability to multimodal services: Through dynamic parsing of modal fields and PHV mapping, it can flexibly support various service semantics such as slicing, latency level, and tenant under Ethernet. At the same time, it can link with the scheduling mechanism of the traffic management module (TM) to accurately match the SLO requirements of different modal services and expand the network service coverage scenarios.

[0021] 6. Enhanced network observability and closed-loop optimization capabilities: Active measurement probes are introduced into the traffic management module, which, combined with passive statistical data, form a real-time service quality monitoring system. The controller can dynamically issue flow table scaling and resource migration instructions based on SLO indicators and congestion signals, realizing closed-loop optimization of "monitoring-analysis-adjustment" and continuously ensuring service quality.

[0022] 7. Guarantee of deployment compatibility and technological evolution: The southbound interface is compatible with mainstream protocols such as P4Runtime, NETCONF, and gRPC, which can be integrated and deployed without large-scale modification of existing network equipment. At the same time, it reserves space for technical expansion, which can facilitate subsequent functional iteration and upgrades as business needs and technology develop. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. The drawings are merely illustrative of some embodiments of the present invention and are not intended to limit the scope of the present invention to all embodiments.

[0024] Figure 1 This is a diagram illustrating the collaborative architecture of the centralized controller and the built-in acquisition controller of the multimodal network element in an embodiment of the present invention. Figure 2 This is a schematic diagram of the multimodal network element structure according to an embodiment of the present invention. Detailed Implementation

[0025] The exemplary solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art.

[0026] To address the core issues of complexity and low efficiency in traditional SDN architectures, this invention discloses a hierarchical control software-defined network architecture for multimodal networks. This architecture includes a centralized controller and multiple multimodal network elements with built-in containerized acquisition controllers. The centralized controller connects to each multimodal network element via an out-of-band management channel, and the multimodal network elements synchronize their states through a flooding protocol. The centralized controller is used for the partitioning, allocation, orchestration, and management of multimodal services, determining the required port, queue, and flow table resources for each network mode, and receiving local state information (network element capabilities, resource views, performance metrics, etc.) reported by each acquisition controller. The acquisition controller is deployed on each multimodal network element and is used to obtain the local state of the network element through the gNMI API and OpenConfig data model, encapsulate state acquisition messages, and send them to other network elements via the flooding protocol. It constructs a global network view, performs local capacity-aware path calculation based on the allocation results from the centralized controller and the global network view, and programs strict source routing. Specifically: 1. Dual controller responsibility division and communication: Multimodal network elements have built-in data acquisition controllers: 1) The acquisition controller is containerized and deployed on each multimodal network element.

[0027] 2) The data acquisition controller obtains local status (link status, utilization, resource view, PHV / table / queue / congestion / probe indicators, etc.) from the network element through the gNMI API and OpenConfig data model.

[0028] 3) The data acquisition controller reports the collected local information to the centralized controller through the out-of-band management channel.

[0029] 4) Local Core Responsibilities: First, accurately encapsulate status collection messages. Collect key information such as local link status, interface utilization, PHV / table / queue / congestion / probe metrics from network elements via the gNMI API and OpenConfig data model, and encapsulate them into messages containing node ID, link ID, sequence number, etc., according to standardized formats to ensure the integrity and traceability of status data. Second, efficiently execute status flooding. Relying on a consensus-free flooding protocol similar to IS-IS or BGP link status propagation mechanisms, synchronize the encapsulated status messages to other network elements, laying the foundation for global status sharing. Third, independently construct a global network view. Receive and integrate status collection messages from all network elements across the network, and generate a local view containing network topology information. The system provides a complete and consistent global view of information such as link status and traffic demand, providing accurate data support for path calculation; fourth, it conducts local capacity-aware path calculation, based on the multimodal service allocation results and global view issued by the centralized controller, runs the corresponding mode's TE algorithm, and selects the optimal set of paths with this network element as the entry point, ensuring that the path adapts to the service capacity requirements; fifth, it strictly programs source routing, uses multimodal identification tags to encode path information, and adds a tag stack to the data packet through two-level table lookup (target IP looks up exit network element, exit network element looks up weighted source route), clearly guiding the forwarding path of the data packet in the network, ensuring accurate and controllable forwarding.

[0030] Centralized controller: 1) Receive information reported by each network element acquisition controller through the out-of-band management channel.

[0031] 2) The core responsibilities are: to be responsible for the division, allocation, orchestration and management of multimodal services, and to determine how many ports, queues and flow table resources are needed for each network mode.

[0032] 2. Global network view construction and path calculation: 1) Global Network View Construction: The built-in acquisition controller of the multimodal network element encapsulates "status acquisition messages" and sends them to other network elements through a flooding protocol (similar to IS-IS or BGP link state propagation mechanism) based on a simple, efficient, and consensus-free requirement. Each network element instance that receives the status message integrates the latest status of all nodes, thereby independently constructing a complete and consistent global network topology and traffic view locally.

[0033] 2) Local TE path calculation: The acquisition controller runs the TE algorithm of each network modality service. Based on the allocation results of multimodal services by the centralized controller, it calculates the capacity-aware path of a certain modality service based on the global view and selects the set of paths with this network element as the entry point.

[0034] 3) Strict Source Routing Programming and Forwarding: Multimodal identification labeling is used to encode paths. The acquisition controller of the ingress multimodal network element on each network mode service is responsible for programming strict source routing, encoding path information into a label stack or packet header extension to guide data packets through the network. Specifically, this involves adding a label stack to the data packet through a two-level table lookup (looking up the exit network element from the destination IP; looking up the weighted source route from the exit network element). Strict source routing is a forwarding method where the complete path of the data packet is calculated at the first entry point into the network and encoded in the packet header. Subsequent intermediate network elements have no right to change the path independently and must strictly follow this preset route map, forwarding hop-by-hop until the destination.

[0035] The collaborative architecture of the centralized controller and the acquisition controller built into the multimodal network element is as follows: Figure 1 As shown, the centralized controller is connected to the multi-modal network elements through an out-of-band management channel, which is mainly used for service management and resource allocation. The network elements synchronize their states through flooding, and path planning is the responsibility of the ingress network element. This ensures that the service network is not interrupted even if the out-of-band management channel fails.

[0036] The core data plane of this network architecture is implemented in multimodal network elements, aiming to provide high flexibility, high resource utilization, and programmability to support fine-grained processing and forwarding of multimodal service flows. The control plane of the multimodal network elements (mainly including the acquisition controller) is responsible for generating policies, while the data plane (mainly including the data path processing module, traffic management module, and flow table resource pooling module) is responsible for efficient policy execution. The multimodal network element structure is as follows: Figure 2 As shown below, the data plane modules of the multimodal network element are described in detail.

[0037] 1. Network element port: Multimodal network elements receive and send data packets through multiple sets of Ethernet MACs (8).

[0038] 2. Data path processing module The data path processing module includes an ingress processing pipeline and an egress processing pipeline. Both the ingress and egress processing pipelines contain a Parser / Deparser module, an MAU pipeline, and a recirculating path.

[0039] 1) Parser / Deparser module: Ingress Parser: Responsible for parsing input data packets, extracting packet header fields, and mapping them to PHV (Packet Header Vector). It also extracts metadata (such as input port, timestamp, etc.) and payload.

[0040] Egress Parser: Responsible for re-parsing PHVs that may be modified during forwarding, or for performing final encapsulation for outgoing packets.

[0041] Unified Reuse: The Parser / Deparser instances of Ingress and Egress are reconfigurable and reusable in a unified manner. The field extraction / encapsulation logic can be dynamically adjusted according to the loaded modal configuration to reduce duplicate resources and lower update costs.

[0042] 2) MAU production line: The MAU pipeline is configured with a multi-level structure. Each MAU pipeline contains a matching unit and an execution unit. In the ingress processing pipeline, the matching unit searches the flow table using the destination IP address in the packet header vector as the key to find the corresponding tag stack. The execution unit performs the action of adding a tag stack to the packet based on the matching result. In the egress processing pipeline, the matching unit searches the flow table using the top-level tag in the packet header vector as the key to find the action corresponding to that tag. The execution unit performs the actions of popping the top-level tag and rewriting the destination MAC address based on the matching result.

[0043] The specific implementation process of the matching unit and execution unit in the ingress processing pipeline is as follows: After the data packet enters the ingress network element, the MAU's matching unit matches the first-level flow table issued by the acquisition controller according to its target IP and finds the egress network element; then, according to this egress network element, it matches the second-level flow table and finds the corresponding tag stack. The execution unit performs an "add tag stack" action according to the matching result. The specific operation of this action is to physically write the calculated path information (tag stack) into the packet header.

[0044] The MAU pipeline includes: Executor: Receives PHV and Meta, and is responsible for instruction scheduling and flow control.

[0045] Match Unit (MU): Provides a set of PHV operation instructions for matching, status flag processing, field rewriting, etc.

[0046] Action Unit (AU): Executes corresponding actions based on the matching results, such as tagging (adding the tag stack to the message header), modifying fields, mirroring / sampling / marking, etc.

[0047] Dynamic and Multi-level: Both Ingress and Egress are configured with multi-level MAU pipelines. Each MAU provides a set of operation instructions for the PHV (PacketHeader Vector) (matching, flag processing, field rewriting, mirroring / sampling / marking). MAUs can be dynamically plugged in and rearranged by a centralized controller, enabling flexible reconfiguration of data plane processing logic and resource management.

[0048] 3) Recirculating path: Data packets processed by the Ingress module can be directed to the recirculating path, returning to the Ingress entry point for secondary or even multiple processing, to support complex tunnel decapsulation, lookup operations, or function chains.

[0049] 3. Traffic Management Module The traffic management module is located after the ingress processing pipeline and before the egress processing pipeline. It is responsible for the queue management, copying, and scheduling of data packets.

[0050] Functions: Responsible for Packet Queueing, Replication, and Scheduling.

[0051] Programmability: Provides programmable queues, supporting fine-grained scheduling based on priority and modality tags. To ensure Quality of Service (QoS), the acquisition controller allocates differentiated priority queues for different modalities on the same port based on service priority constraints issued by the centralized controller. High-priority queues are allocated to low-latency services, while low-priority queues guaranteeing bandwidth are allocated to high-bandwidth services. The Traffic Management Module (TM) receives queue scheduling policies from the acquisition controller. When a data packet arrives, the module parses its modality tag and, according to the preset "modality tag - queue priority" mapping rule in the policy, places the data packet into the corresponding priority queue. The scheduling phase follows the "highest priority, first service" principle, ensuring that the forwarding needs of critical services such as low-latency services are met first.

[0052] Congestion Management: Implements an active congestion management mechanism based on congestion signals and ECN / ECT.

[0053] Measurement probe: Supports sampling / staking measurement probe functionality.

[0054] Control Interaction: Traffic Manager interacts with the network element acquisition controller through the P4Runtime and NETCONF / YANG model interfaces, reporting information such as queue status and congestion indicators, and receiving programming instructions for scheduling and queue parameters.

[0055] 4. Flow table resource pooling module The flow table resource pooling module adopts an efficient and flexible table resource layer design, located between the data path processing module and the traffic management module, and is accessed by the matching unit through a selection access mechanism. The flow table resource pooling module adopts a Buddy-Slab structure design, including a TCAM resource pool and an SRAM resource pool. Flow table data is deployed in the TCAM resource pool and SRAM resource pool according to storage characteristics (the TCAM resource pool is used for flow tables that require wildcard and priority matching (such as IP routes and ACLs), while the SRAM resource pool is used for flow tables that require precise matching and large-capacity storage (such as precise flow tables and MAC tables)). Both types of resource pools are connected to the matching unit in the MAU pipeline via the Crossbar Internet with high bandwidth and non-blocking connection. The process of deploying flow table data is as follows: The acquisition controller first receives the flow table resource allocation strategy from the centralized controller, clarifying core constraints such as resource block type (TCAM / SRAM), total resource quota, and isolation rules; the acquisition controller combines local path calculation results, global network status, and service forwarding requirements to generate a specific flow table containing matching rules and action instructions, and simultaneously determines the resource size required for the flow table; it sends resource allocation instructions to the flow table resource pool, clarifying the size of the resource blocks to be divided and the storage medium (which must conform to the type specified by the centralized controller), and the resource pool completes the resource block partitioning through a buddy allocation algorithm; after the resource blocks are partitioned, the acquisition controller distributes the generated specific flow table to the dedicated resource block for storage, ensuring accurate matching between the flow table and resource configuration.

[0056] TCAM resource pool: Employs a Buddy-Slab structure, with Bank n row groups. Buddy indicates that TCAM resources are divided into multiple Banks and managed using the Buddy Allocation algorithm. This allows for fast partitioning and reclamation of TCAM resources from minimum allocation blocks to larger table segments by row group.

[0057] SRAM resource pool: adopts Buddy-Slab structure, Bank n Buddy tree: indicates that SRAM resources are also divided into multiple banks and managed through buddy allocation algorithm to achieve pooling management and flexible allocation.

[0058] Crossbar Interconnection: A crossbar is configured above the resource pool to decouple the requests of the matching unit from the access of the underlying Bank, enabling high-bandwidth, non-blocking resource access and avoiding single-link bottlenecks.

[0059] Flow table query path: The Match Unit (MU) initiates the flow table query request. The Table Storage Unit (TSU) stores the actual match table resources and consists of a hybrid TCAMBank and SRAMBank. The Crossbar interconnect network forms the core switching structure for resource pooling, connecting the initiator (MU) of the flow table request and the storage unit (TSU) of the resources. It supports flow table isolation and segmentation by modal table tenants through a centralized controller. A partner allocation strategy is used to allocate TCAM / SRAM resources proportionally, enabling rapid partitioning and reclamation from minimum allocation blocks to large table entries.

[0060] 5. Data packet forwarding path Data packets enter the Ingress pipeline from Ethernet MACs for parsing and initial matching, then proceed to Traffic Manager for queuing, scheduling, and replication. Scheduled packets, carrying forwarding path information, enter the Egress pipeline for final encapsulation and modification, and are ultimately sent out via Ethernet MACs. During matching operations, the Ingress and Egress modules efficiently utilize shared flow table resources by selecting the access layer.

[0061] This invention also discloses a data forwarding method for a hierarchical control software-defined network architecture in a multimodal network, comprising the following steps: Step S1: After the multimodal network element is started, the acquisition controller collects local status information through the gNMI API and generates status acquisition messages; Step S2: The data acquisition controller sends status acquisition messages to other multimodal network elements through the flooding protocol, and reports them to the centralized controller through the out-of-band management channel; Step S3: Each acquisition controller receives and integrates all status acquisition messages to build a complete and consistent global network view; Step S4: The centralized controller allocates multimodal service resources based on the global network view; Step S5: The acquisition controller of the ingress network element performs local capacity-aware path calculation based on the allocation results and the global network view to generate strict source routes; Step S6: The ingress network element adds a label stack to the data packet through a two-level table lookup, the intermediate network element forwards the data packet according to the label and pops the stack, and the egress network element completes the final encapsulation of the data packet and sends it.

[0062] The two-level table lookup in step S5 is as follows: the first level looks up the egress network element through the target IP, and the second level looks up the corresponding multimodal label stack through the egress network element.

[0063] Furthermore, when a link failure occurs in the network, the acquisition controller of the network element where the failed link is located immediately activates the local repair path, forwards the data packets to the alternative link, and floods the updated status acquisition messages; after receiving the updated status messages, the ingress network element recalculates the path, completing the rapid update of the entire network path.

[0064] The acquisition controller generates flow table resource allocation instructions based on the multimodal service resource allocation strategy issued by the centralized controller and the locally constructed global network view. The flow table resource pooling module receives the instructions and dynamically divides the TCAM resource pool / SRAM resource pool through the partner allocation algorithm.

[0065] This invention aims to address the technical problems of "high complexity, frequent failures, slow convergence, and low utilization" in the control plane of SDN network architecture. A centralized controller orchestrates service modes on demand based on multimodal network services and determines the required port, queue, and flow table resources for each mode, performing closed-loop adjustments based on the data acquisition controller's transmission status. By eliminating dependence on external control functions, the network architecture is simplified, reducing failure points and failure modes, and lowering testing and maintenance difficulty. Simultaneously, it retains the core advantages of SDN (centralized management and control, high network utilization, consensus-free path computation), improving routing convergence speed, reducing SLO impact, and ultimately achieving a dual improvement in availability and efficiency at the control plane. For the data plane, addressing the rigid configuration and inefficient utilization of data plane resources in SDN network architecture, a collaborative architecture of "data acquisition controller + multimodal network elements" is provided. The data acquisition controller is responsible for distributed state flooding, building a global network view, performing local capacity-aware path computation based on the allocation results of the centralized controller, and programming strict source routing. Within the multimodal network element, table resources are centrally constructed using a Buddy-Slab architecture, and fine-grained sharing and dynamic slicing of table resources are achieved through a buddy allocation algorithm. Parser / Deparser ports are uniformly multiplexed across multiple ports. Programmable flow control / congestion / measurement probes are introduced into the TM (Transaction Manager). Ultimately, this improves table resource utilization and migration efficiency, reduces hot table conflicts and reconfiguration interruption time, and achieves low latency and deterministic bandwidth guarantees in multimodal scenarios on the data plane.

[0066] The following example of "multimodal service carrying of data center backbone" is given to better understand the solution of the present invention.

[0067] The network element architecture is implemented based on FPGA, with a fixed number of 8 ports per network element; the flow table resource pooling module provides a hybrid TCAM / SRAM of 64MB; the minimum table block has 512 entries; the MAU chain depth is 12; two sets of Parser / Deparser multiplex 8 ports; and TM provides 8 priority levels and ECN.

[0068] A centralized controller is developed based on Python scripts. The controller allocates TCAMs (Transaction Management Tables) to security / ACL tables requiring wildcard matching based on the modal definition of "tenant × application × latency level," while SRAM is used for flow tables requiring precise matching. For hot tenants, hot tables are expanded and migrated to adjacent MAUs within a single network element according to flow type, reducing cross-layer forwarding. The data acquisition controller interfaces with network elements via the gNMI API, while the centralized controller interfaces with programming forwarding tables via the P4Runtime API.

[0069] Operation process: After the network element starts up, the data acquisition controller subscribes to the link status, interface utilization, traffic demand data, network element capability model and resource view, and PHV / table / queue / congestion / probe indicators of the network element master through gNMI, and generates status acquisition messages (including node ID, link ID, sequence number, queue information, and network element capability model). Status acquisition messages are flooded to other network elements through the data plane and sent to the centralized controller for storage and management. Each network element acquisition controller receives and integrates the status acquisition messages to build a global view containing 20 nodes and 40 links. The centralized controller distributes improved TE algorithm tags to each network element based on a global view; Based on the label selection, the corresponding built-in TE algorithm is used to calculate 40 flow paths with this network element as the entry point, and a weighted source route list is output. The data acquisition controller uses two levels of table lookup rules (the first level is the table from IP to the egress network element, and the second level is the table from the egress network element to the multimodal label stack). The ingress network element adds a label stack to the data packet, and the intermediate network elements forward the data according to the label and pop the stack. When a simulated link failure occurs, the network element where the failed link is located enables the local repair path and forwards the data packets to the alternative link. At the same time, it floods the updated status collection messages. After receiving the updated messages, the ingress network element recalculates the path and completes the network-wide path update within 5 seconds.

[0070] Results: The CPU utilization rate of the network element's main control unit remained stable below 45%, the median route convergence time was significantly reduced, the number of "bad seconds" for high-priority traffic was significantly reduced, and network utilization remained above 90%. Under mixed loads, the utilization rate of the network element's flow table resource blocks was significantly improved.

[0071] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A hierarchical control software-defined network architecture for multimodal networks, characterized in that, The system includes a centralized controller and multiple built-in containerized acquisition controllers for a multimodal network element. The centralized controller is connected to each multimodal network element through an out-of-band management channel, and the multimodal network elements achieve state synchronization through a flooding protocol. The centralized controller is used for the division, allocation, orchestration and management of multimodal services, determines the port, queue and flow table resources required for each network mode, and receives local status information reported by each acquisition controller. The acquisition controller is deployed on each multimodal network element to acquire the local status of the network element, encapsulate the status acquisition message and send it to other network elements through the flooding protocol, construct a global network view, perform local capacity-aware path calculation based on the allocation result of the centralized controller and the global network view, and program strict source routing.

2. The hierarchical control software-defined network architecture for multimodal networks according to claim 1, characterized in that, The control plane of the multimodal network element includes an acquisition controller, and the data plane includes a data path processing module, a traffic management module, and a flow table resource pooling module. The data path processing module includes an inlet processing pipeline and an outlet processing pipeline, both of which contain a Parser / Deparser module and an MAU pipeline; The flow management module is located after the inlet processing pipeline and before the outlet processing pipeline, and is responsible for the queue management, copying and scheduling of data packets; The flow table resource pooling module adopts a Buddy-Slab architecture design, which includes a TCAM resource pool and an SRAM resource pool. Flow table data is classified and deployed in the TCAM resource pool and SRAM resource pool according to storage characteristics. Both types of resource pools are connected to the matching unit in the MAU pipeline with high bandwidth and non-blocking through a Crossbar switching architecture.

3. The hierarchical control software-defined network architecture for multimodal networks according to claim 2, characterized in that, The Parser / Deparser module supports unified reuse across multiple ports and dynamically adjusts the field extraction and encapsulation logic based on the loaded modal configuration.

4. The hierarchical control software-defined network architecture for multimodal networks according to claim 2, characterized in that, The MAU pipeline is configured as a multi-level structure, and each MAU pipeline includes a matching unit and an execution unit; In the ingress processing pipeline, the matching unit searches the flow table using the network mode identifier address of the packet header vector as the key to find the corresponding tag stack; the execution unit performs the action of adding a tag stack to the packet based on the matching result. In the outgoing processing pipeline, the matching unit searches the flow table using the top-level label in the packet header vector as the key to find the action corresponding to that label; The execution unit performs the actions of popping up the top-level label and rewriting the target MAC based on the matching result.

5. The hierarchical control software-defined network architecture for multimodal networks according to claim 2, characterized in that, The traffic management module supports a programmable scheduling mechanism based on modal tags and interacts with the acquisition controller through the P4Runtime or NETCONF / YANG interface. The traffic management module receives the scheduling policy issued by the acquisition controller. When a data packet arrives, the module parses its modal tag and puts it into the corresponding priority queue according to the mapping rules in the policy.

6. The hierarchical control software-defined network architecture for multimodal networks according to claim 2, characterized in that, Both the TCAM resource pool and the SRAM resource pool adopt a Buddy-Slab structure. After receiving the resource allocation instructions issued by the acquisition controller, the resource pool realizes fine-grained resource allocation through the buddy allocation algorithm.

7. A data forwarding method based on a hierarchical control software-defined network architecture of a multimodal network according to any one of claims 1-6, characterized in that, include: After the multimodal network element is started, the data acquisition controller collects local status information and generates status acquisition messages; The data acquisition controller sends status acquisition messages to other multimodal network elements via a flooding protocol and reports them to the centralized controller via an out-of-band management channel. Each data acquisition controller receives and integrates all status acquisition messages to build a complete and consistent global network view; The centralized controller allocates multimodal service resources based on a global network view; The acquisition controller of the ingress network element performs local capacity-aware path calculation based on the allocation results and the global network view to generate strict source routes; The ingress network element adds a label stack to the data packet through a two-level table lookup. The intermediate network element forwards the data packet according to the label and pops it from the stack. The egress network element completes the final encapsulation of the data packet and sends it.

8. The data forwarding method for a hierarchical control software-defined network architecture in a multimodal network according to claim 7, characterized in that, The two-level table lookup is as follows: the first level looks up the egress network element through the network modality identifier address, and the second level looks up the corresponding multimodal tag stack through the egress network element.

9. The data forwarding method for a hierarchical control software-defined network architecture in a multimodal network according to claim 7, characterized in that, When a network link failure occurs, the acquisition controller of the network element where the failed link is located immediately activates the local repair path, forwards the data packets to the alternative link, and floods the updated status acquisition messages. After receiving the updated status message, the ingress network element recalculates the path, completing a rapid update of the entire network path.

10. The data forwarding method for a hierarchical control software-defined network architecture in a multimodal network according to claim 7, characterized in that, The acquisition controller generates flow table resource allocation instructions based on the multimodal service resource allocation strategy issued by the centralized controller and combined with the locally constructed global network view. The flow table resource pooling module receives the instructions and dynamically divides the TCAM resource pool / SRAM resource pool through the partner allocation algorithm.

Images