Air-sea cross-domain network slice configuration and response method based on ctc8180 chip

Abstract

The application discloses a kind of based on CTC8180 chip's air sea cross-domain network slice configuration and response method, belongs to air sea cross-domain communication and network slice technical field, including S1.Configuration and parallel access NETCONF with CLI passage, convert configuration instruction CTC8180 chip call instruction;S2.Based on FlexE technology creates resource pool, logical port, binding interface and VRF strategy;S3.Combined with SRv6 path programming, service level mapping and gport identification slice identification, complete the forwarding and mapping configuration of slice strategy;S4.Through three kinds of protocol monitoring performance, data acquisition and fault detection;S5.Through resource dynamic adjustment, path switching and strategy linkage etc. form closed loop control, S6.The steps of integration S1-S5 realize multi-chip compatibility and stable adaptation deployment.The application provides a kind of specific implementation method for constructing logical network slice capability on high-performance forwarding hardware facing air sea cross-domain specific demand, provides reliable communication guarantee for high dynamic, heterogeneous service.

Description

Technical Field

[0001] This invention belongs to the field of air-sea cross-domain communication and network slicing technology, specifically relating to a method for configuring and responding to air-sea cross-domain network slices based on the CTC8180 chip. Background Technology

[0002] With the continuous evolution of air-sea cross-domain network technology, the types of services it carries are becoming increasingly diversified, covering various heterogeneous functions such as communication, detection, and navigation. These services exhibit significant differences in network bandwidth, latency, reliability, and isolation, posing stringent and diverse requirements on network performance.

[0003] Traditional networks employ a rigid architecture design, with their data forwarding strategies and control logic tightly coupled. This often requires the reconstruction of the entire network protocol or even adjustments to the hardware configuration when switching between task modes (from one task mode to another). Their adaptive capabilities are severely insufficient, making it difficult to support the dynamic scheduling and fine-grained on-demand allocation of network resources in multi-task parallel scenarios.

[0004] Network slicing technology is considered a key path to solve the aforementioned problems and achieve flexible allocation of network resources. The core of this technology lies in dividing a single physical network into multiple independent logical slices, each serving a specific task or service type, thus achieving "one network, multiple uses" on a single physical network. Currently, slicing technology in 5G terrestrial networks is relatively mature, but its slicing paradigm is mainly based on abstract definitions of general service types. Examples include enhanced mobile broadband slices (eMBB) for high bandwidth demands, ultra-reliable low-latency communication slices (uRLLC) for high reliability and low latency, and massive machine-type communication slices (mMTC) supporting massive device connections. However, air-sea cross-domain networks have distinct characteristics such as highly dynamic nodes, frequent topology changes, and heterogeneous links. Their service models typically need to be deeply customized to specific tasks (such as specific reconnaissance tasks, command and control chains, etc.), which is fundamentally different from the general service models of terrestrial networks. This makes it difficult to directly transplant 5G slicing solutions based on service paradigms to be applied to air-sea cross-domain scenarios.

[0005] Furthermore, existing research on air-sea cross-domain network slicing largely focuses on control plane architecture design and resource allocation algorithms, lacking an efficient and reliable execution platform on the forwarding plane of heterogeneous node devices. Especially in resource-constrained and complex network edge nodes, there is an urgent need for a component-based software architecture that can deeply integrate underlying hardware characteristics and achieve fine-grained resource isolation and policy execution. This lack of an architecture has become a key bottleneck restricting the transition of air-sea cross-domain network slicing technology from theory to practical deployment. Summary of the Invention

[0006] To address the shortcomings of existing technologies, such as insufficient availability and flexibility of slice policy reception, poor physical layer resource isolation, lack of differentiated mechanisms for cross-domain traffic forwarding, and inaccurate service level identification and slice identifier identification, this invention provides a cross-domain network slice configuration and response method based on the CTC8180 chip. It ensures high availability of policy reception by constructing dual configuration paths of NETCONF and CLI, achieves physical layer resource isolation based on FlexE technology, combines SRv6 path programming and QoS mapping to achieve differentiated forwarding of cross-domain traffic and service level identification, and achieves efficient slice packet identification through precise connection between slice identifiers and packet forwarding. Ultimately, it forms a closed-loop management solution for the entire process, improving the service stability and service adaptability of network slices.

[0007] The technical solution adopted in this invention:

[0008] A method for configuring and responding to cross-domain air-sea networks based on the CTC8180 chip is as follows:

[0009] S1. Initiate slice configuration request, standardize the slice configuration command in a unified format, configure and connect to NETCONF and CLI channels in parallel, convert the configuration command into API call command that can be recognized by CTC8180 chip SDK and send it, realize slice strategy reception and execution;

[0010] S2. With the help of the CTC8180 chip SDK, API call instructions can be recognized. Based on FlexE technology, by creating a FlexEGroup resource pool and FlexE Client logical port, binding the L3 interface and configuring VRF policy, the FlexEClient logical port of the bound business is obtained, which is used to realize the isolation of slice physical layer resources and business deployment.

[0011] S3. Based on the CTC8180 chip SDK, it can identify API call commands and the FlexE Client logical port bound to the service. Combined with SRv6 path programming, service level mapping and slice identification through gport, it completes the forwarding and mapping configuration of slice policy.

[0012] S4. Based on the slice strategy, forwarding and mapping configuration adopts TWAMP Light performance measurement, Telemetry data collection and BFD fast detection to monitor slice link performance and collect status data in real time and quickly detect faults, triggering alarms to support optimization and recovery;

[0013] S5. Set up a dynamic resource adjustment strategy and a path switching strategy. Trigger dynamic resource adjustment and path switching by detecting fault results. Through the dynamic resource adjustment strategy, path switching strategy, strategy linkage and confirmation feedback results, a closed-loop control of "perception-decision-execution-confirmation" is formed.

[0014] S6. The steps of integrating S1-S5 are completed through multi-chip image support, kernel-mode driver and CLI integration to complete system driver and integration configuration, and realize network slice configuration and response.

[0015] Preferably, in step S1, the configuration instructions are converted into API instructions recognizable by the CTC8180 chip SDK and sent. The configuration includes NETCONF interface configuration, CLI interface configuration, and an adaptation mechanism, as detailed below:

[0016] NETCONF Interface Configuration: When receiving configuration commands using the NETCONF interface, the slicing strategy data structure is defined based on the standardized YANG data model. Configuration commands are sent through Remote Procedure Call (RPC) messages in Extensible Markup Language format. The configuration process includes establishing a session, locking the configuration set, editing the candidate dataset, and submitting and unlocking the running dataset.

[0017] CLI Interface Configuration: When receiving slicing strategy configuration instructions through the CLI interface, it provides a command-line instruction set for operation and maintenance scenarios, supporting operation and maintenance personnel to write script files containing multiple command-line instructions, and to achieve batch deployment of slicing strategies and rapid fault recovery in abnormal scenarios through scripting.

[0018] Adaptation mechanism: The slicing strategy configuration instructions received by the NETCONF interface and CLI interface are standardized and processed in a unified format. The configuration instructions of both channels are converted into application programming interface (API) call instructions of the underlying CTC8180 chip software development kit. The converted API call instructions are sent to the CTC8180 chip to realize the mapping between the abstract strategy and the chip hardware behavior, and complete the reception and execution of the slicing strategy.

[0019] Preferably, in step S2, the FlexE Client logical port for the bound business is obtained. The relevant configuration of the port includes FlexE function initialization, FlexE Group creation, Client slice instantiation, and business interface binding, as follows:

[0020] FlexE function initialization: Call the ctcs_flexe_serdes_enable() interface provided by the CTC8180 chip SDK to specify the FlexE working mode of the serializer / deserializer and complete the underlying hardware initialization of the FlexE function.

[0021] FlexE Group Creation: The ctcs_flexe_group_create() interface is called to create a FlexE Group resource pool, which is used to aggregate the bandwidth resources of multiple physical ports; then, the specified physical port is added to the FlexE Group through the ctcs_flexe_group_add_phy() interface to realize the aggregation of physical port bandwidth and form a dynamically allocable shared bandwidth resource pool.

[0022] Client slice instantiation: The ctcs_flexe_client_create() interface is called to create a FlexE Client logical port. Each FlexE Client logical port represents a network slice, which serves as a resource carrier entity at the physical layer. The ctcs_flexe_client_add_cal_slot() interface is used to dynamically allocate dedicated time slots for each FlexEClient from the FlexE Group resource pool. The number of time slots allocated is positively correlated with the bandwidth requirements of the slice, thereby achieving bandwidth isolation and precise control between different slices.

[0023] Service Interface Binding: The created FlexE Client logical port is bound to a Layer 3 interface. An L3 interface is created by calling the ctcs_l3if_create() interface, and then the virtual route forwarding attribute is configured for the L3 interface by the ctcs_l3if_set_property() interface to achieve route isolation for the slice. It also supports the configuration of loading virtual LAN isolation policies and quality of service priority scheduling policies. That is, a hardware-isolated FlexE Client logical port is created for each network slice, and this port is bound to the L3 interface and basic service policies such as VRF / VLAN / QoS. This is used to complete the entire process of slice implementation from physical layer resource isolation to service policy deployment, and finally completes the reception, conversion and execution of slice policies.

[0024] Preferably, in step S3, the forwarding and mapping configuration of the slice strategy is completed by combining SRv6 path programming, service level mapping, and slice identification through gport identifiers to achieve differentiated forwarding and service level identification of cross-domain traffic, as detailed below:

[0025] SRv6 path programming: The CTC8180 chip SDK's ctcs_srv6_add_my_sid() interface is called to configure segment identifiers, supporting SID configuration in three formats: Traditional SID, uSID, and gSID. Combined with the nexthop add srv6 command, the next-hop node corresponding to each SID is specified to construct the forwarding path of the end-to-end SRv6 traffic engineering strategy, realizing path planning and precise forwarding of cross-domain traffic.

[0026] Service level mapping: The access control list is configured by calling the ctcs_acl_add_entry() interface of the CTC8180 chip SDK, and the target service flow is matched through ACL rules; a mapping rule is established based on the QoS Table-map, and the external differential service code point value of the matched service flow is mapped to the internal priority and color of the device, forming a one-to-one correspondence between service level and forwarding priority;

[0027] Slice identification: The CTC8180 chip SDK's ctcs_set_internal_port() interface is called to assign a unique global port number to each FlexE Client logical port, using gport as the core identifier of the slice; when the device receives a packet, it identifies the corresponding FlexE Client logical port by parsing the gport information carried in the packet, thereby determining the network slice to which the packet belongs, realizing the forwarding and mapping configuration of the slice policy, and achieving closed-loop management of the entire slice service process.

[0028] Preferably, in step S4, TWAMP Light performance measurement, Telemetry data acquisition, and BFD rapid detection are used to monitor slice link performance in real time, collect status data, and quickly detect faults, triggering alarms to support optimization and recovery, as detailed below:

[0029] TWAMP Light performance measurement: Configure ACL rules in the forwarding nodes of the network slice, use TWAMP Light measurement packets with destination UDP port 5000 as the matching object, filter non-measurement packets to reduce invalid data transmission; call the ctcs_packet_rx_register() interface provided by the forwarding chip to register the TWAMP packet receiving callback function. When the forwarding node receives a TWAMP Light packet that matches the ACL rules, trigger the callback function to send the packet to the CPU for processing first, avoiding the packet being dropped in the forwarding plane;

[0030] Telemetry data acquisition: A data acquisition channel is built based on the in-band network telemetry mechanism. By configuring the INT acquisition rules of each network node on the slice forwarding path, path status data is collected in real time. The collected status data is pushed to the remote analysis platform through the specified reporting channel to provide data support for slice link optimization, resource scheduling and fault prediction.

[0031] BFD Fast Detection: This feature performs full-process detection of slice services. It defines a `ctc_oam_key_t` structure to store key identification information for the BFD session and a `ctc_oam_lmep_cfg_t` structure to configure the BFD session's runtime parameters. It calls the `ctcs_oam_add_lmep()` API of the CTC8180 chip SDK to instantiate the BFD session based on the configuration information of the two structures. This BFD session supports multiple encapsulation types, including IP, tag switching path, and virtual circuit connection verification, with a detection cycle down to the millisecond level. When a slice link experiences an interruption or a sudden delay, the BFD session quickly detects and triggers a fault alarm, providing support for rapid fault location and recovery.

[0032] Preferably, in step S5, the resource dynamic adjustment strategy, path switching strategy, strategy linkage, and confirmation feedback results are implemented as follows:

[0033] Dynamic resource adjustment strategy: The status awareness and acquisition submodule pushes the collected link congestion status and bandwidth utilization performance data to the dynamic decision-making unit; when slice link congestion or bandwidth demand changes are detected, the dynamic decision-making unit automatically generates resource adjustment instructions, calls the ctcs_flexe_client_add_cal_slot() interface of the CTC8180 chip SDK to add time slot resources to the slice to expand bandwidth, or calls the ctcs_flexe_client_remove_cal_slot() interface to reduce slice time slot resources to shrink bandwidth, ensuring that slice resources are accurately matched with business needs;

[0034] Path switching strategy: When the BFD detection unit detects a failure in the primary SRv6 TE path, it immediately triggers the control plane path recalculation process. The control plane replans the backup path based on the remaining link resources, updates the next-hop mapping relationship of the segment identifier by calling the ctcs_srv6_update_my_sid() interface, or directly updates the device forwarding table entries, seamlessly switching the slice service traffic from the primary path to the backup path, reducing the duration of the failure's impact on services.

[0035] Policy linkage and confirmation: After resource adjustment or path switching is completed, the policy execution result is fed back through two channels: firstly, through the NETCONF protocol. <rpc-reply>The system first feeds back the configuration execution status to the upper-level controller; secondly, it reports the adjusted slice performance data to the remote analysis platform through the Telemetry channel; after receiving the feedback information, the upper-level controller or analysis platform completes the policy execution confirmation, forming a complete closed-loop control of "perception-decision-execution-confirmation".

[0036] Preferably, in step S6, the integration of steps S1-S5 is achieved through multi-chip image support, kernel-mode driver, and CLI integration to complete the system driver and integration configuration, as detailed below:

[0037] Multi-chip image support: Build a unified compilation system framework and configure the CHIPNAME variable as the chip model identifier through Makefile script; in the compilation process, dynamically match the SDK interface definition, driver and hardware adaptation parameters of the target chip based on the value of the CHIPNAME variable; shield the hardware difference code between different chips through conditional compilation mechanism, realize the compatible deployment of the same system image for multiple chips, and reduce the system maintenance cost in multi-chip scenarios;

[0038] Kernel-mode driver: Based on the Linux kernel driver development specification, chip access layer driver code is written and compiled to generate the dal.ko kernel module. This kernel module integrates the low-level hardware access interface of the CTC8180 chip, including register operations, interrupt handling, and resource scheduling core functions, providing kernel-level chip access capabilities for the upper-layer SDK. The dal.ko module is loaded through the insmod or modprobe commands to complete the driver and kernel adaptation and ensure that upper-layer applications access chip hardware resources through standardized interfaces.

[0039] CLI Integration: Establishes a communication architecture between the ctc-shell client and the SDK Server; the ctc-shell client provides a command-line interface, supporting operations and maintenance personnel to input slicing strategy configuration, status query, and fault recovery commands; the SDK Server, acting as a server, receives command requests from the ctc-shell client and, through interaction with the kernel-mode dal.ko driver module, converts the commands into chip-recognizable operations; it also supports remote login access to the ctc-shell client, enabling remote configuration and operation status query of remote CTC8180 chip devices.

[0040] Compared with existing technologies, this invention proposes a method for configuring and responding to cross-domain air-sea networks based on the CTC8180 chip. The advantages of this method are:

[0041] (1) It enables the deployment and management of network slicing services on switching hardware that does not have native advanced slicing capabilities.

[0042] This invention employs a systematic approach to orchestrate multiple independent hardware functions at the CTC8180 chip's underlying layer, such as FlexE resource isolation, QoS queue scheduling, and route isolation, thereby constructing logical network slices with independent resources, independent forwarding planes, and differentiated service levels at the hardware level. This method solves the technical problem that upper-layer slicing service requirements cannot be directly mapped to underlying general-purpose hardware.

[0043] (2) Provides a refined resource scheduling solution for specific challenges across air and sea domains.

[0044] This method addresses the significant bandwidth differences between air and sea areas by employing asymmetric traffic shaping and multi-level queue scheduling strategies. This effectively manages cross-domain traffic, preventing congestion and indiscriminate packet dropping. Simultaneously, by constructing deterministic forwarding paths using SRv6 technology, it ensures the Quality of Service (SLA) for high-priority services on resource-constrained links, thereby improving task reliability.

[0045] (3) It enhances the network’s ability to adapt to highly dynamic link environments.

[0046] By integrating hardware-level fast detection protocols such as BFD, this method can achieve millisecond-level perception of link status and establish an automated response closed loop. When link performance deteriorates or a failure occurs, this mechanism can automatically trigger dynamic adjustments to slice resources or switching of forwarding paths, improving service continuity and network stability to adapt to the dynamic changes in air-sea cross-domain communication environments. Attached Figure Description

[0047] Figure 1 This is an overall flowchart of the air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip of the present invention;

[0048] Figure 2 This is a flowchart of the NETCONF protocol for the air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip of this invention. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be further described clearly and completely below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0050] To make the inventive objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings: In order to better understand the above-mentioned objectives, features, and advantages of this invention, the advantages of this invention will be further illustrated below by comparing the embodiments with the accompanying drawings and specific implementation methods.

[0051] This invention proposes a method for configuring and responding to cross-domain air and sea networks based on the CTC8180 chip, such as... Figure 1 As shown, it includes a slice policy receiving module, a hardware resource isolation instantiation module, a policy forwarding and mapping module, a state awareness and acquisition module, a dynamic response control module, and a system driver and integration module, as detailed below:

[0052] S1. Initiate slice configuration request, standardize the slice configuration command in a unified format, configure and connect to NETCONF and CLI channels in parallel, convert the configuration command into API call command that can be recognized by CTC8180 chip SDK and send it, realize slice strategy reception and execution;

[0053] Specifically, in step S1, the configuration instructions are converted into API instructions recognizable by the CTC8180 chip SDK and sent. The configuration includes the configuration of the NETCONF interface, the CLI interface, and the adaptation mechanism, as detailed below:

[0054] The system configures and allows parallel access via both the Network Configuration Protocol Interface (NETCONF) and the Command Line Interface (CLI). The NETCONF interface receives configuration commands for slicing policies from the upper-layer controller via the NETCONF interface, suitable for automated deployment scenarios. The CLI interface receives configuration commands for slicing policies from local operations personnel via the CLI interface, suitable for scripted batch deployment and fault recovery scenarios. This enables parallel access for both the upper-layer controller and local operations personnel, ensuring high availability and flexibility in the issuance of slicing policy configuration commands. The configuration of the slicing policy receiving module includes NETCONF interface configuration, CLI interface configuration, and an adaptation mechanism, as detailed below:

[0055] NETCONF interface configuration, such as Figure 2 As shown: When configuring slicing strategies through the NETCONF interface, the data structure of the slicing strategy is defined based on the standardized YANG (Yet Another Next Generation) data model. This data structure is then transmitted via an RPC message in Extensible Markup Language (XML) format. <edit-config>The system generates configuration instructions for slicing policies and distributes these instructions to network devices through the upper-layer controller. To address issues such as service interruptions, configuration conflicts, and rollback difficulties caused by directly modifying the operational state in network configuration, a transaction-based configuration management method is used. This method constructs the network configuration process using a candidate configuration set as a buffer. The configuration instruction flow includes establishing a session (establishing a NETCONF session with the upper-layer controller), locking the configuration set (constructing and locking the configuration set), and editing the candidate dataset (receiving XML format data from the upper-layer controller). <edit-config>The system processes messages, parses message content and edits candidate datasets, submits and unlocks the running dataset (verifies candidate datasets, submits candidate datasets and unlocks configuration sets after passing verification, and synchronizes the candidate dataset content to the dataset in the configuration set to complete the overall configuration update), achieving atomicity, isolation and rollback of configuration changes, ensuring the security and reliability of network change operations;

[0056] CLI Interface Configuration: When configuring slicing strategies through the CLI interface, configuration commands for slicing strategies are provided in batches through scripting or manual input. This is a command-line instruction set. Local operations and maintenance personnel can log in to the console or SSH to use the command-line instruction set oriented towards operations and maintenance scenarios, which supports rapid fault recovery in abnormal scenarios.

[0057] Adaptation Mechanism: The slicing strategy configuration instructions issued by the NETCONF interface and CLI interface are standardized and processed in a unified format. The configuration instructions of both channels are converted into application programming interface (API) call instructions that can be recognized by the underlying CTC8180 chip software development kit (SDK). The converted API call instructions are sent to the CTC8180 chip to achieve a precise mapping between the slicing strategy and the chip hardware behavior, and to complete the reception and execution of the slicing strategy.

[0058] S2. With the help of the CTC8180 chip SDK, API call instructions can be recognized. Based on FlexE technology, by creating a FlexEGroup resource pool and FlexE Client logical port, binding the L3 interface and configuring VRF policy, the FlexEClient logical port of the bound business is obtained, which is used to realize the isolation of slice physical layer resources and business deployment.

[0059] Specifically, in S2, the logical port of the FlexE Client bound to the business is obtained. The relevant configuration of the port includes FlexE function initialization, FlexE Group creation, Client slice instantiation, and business interface binding, as follows:

[0060] FlexE Function Initialization: Call the ctcs_flexe_serdes_enable() interface provided by the CTC8180 chip SDK to specify the FlexE working mode of the serializer / deserializer (SerDes), complete the underlying hardware initialization of the FlexE function, and lay the foundation for subsequent physical layer hardware resource isolation.

[0061] FlexE Group Creation: The ctcs_flexe_group_create() interface is called to create a FlexE Group resource pool, which is used to aggregate the bandwidth resources of multiple physical ports; then, the specified physical port is added to the FlexE Group through the ctcs_flexe_group_add_phy() interface to realize the aggregation of physical port bandwidth and form a dynamically allocable shared bandwidth resource pool.

[0062] Client slice instantiation: The ctcs_flexe_client_create() interface is called to create a FlexE Client logical port. Each FlexE Client logical port represents a network slice, which serves as a resource carrier entity at the physical layer. The ctcs_flexe_client_add_cal_slot() interface is used to dynamically allocate dedicated time slots for each FlexEClient from the FlexE Group resource pool. The number of time slots allocated is positively correlated with the bandwidth requirements of the slice, thereby achieving bandwidth isolation and precise control between different slices.

[0063] Service Interface Binding: The created FlexE Client logical port is bound to a Layer 3 (L3, i.e., network layer) interface. An L3 interface is created by calling the `ctcs_l3if_create()` interface, and then the Virtual Router Forwarding (VRF) attribute is configured for the L3 interface using the `ctcs_l3if_set_property()` interface to achieve route isolation for the slice. It also supports loading configurations for services such as Virtual LAN (VLAN) isolation policies and Quality of Service (QoS) priority scheduling policies. In other words, a hardware-isolated FlexE Client logical port is created for each network slice, and this port is bound to the L3 interface and basic service policies such as VRF / VLAN / QoS. This completes the entire process of slice implementation from physical layer resource isolation to service policy deployment, ultimately completing the reception, conversion, and execution of slice policies.

[0064] S3. Based on the CTC8180 chip SDK, it can identify API call commands and the FlexE Client logical port bound to the service. Combined with SRv6 path programming, service level mapping and slice identification through gport, it completes the forwarding and mapping configuration of slice policy.

[0065] Specifically, in S3, by combining SRv6 (IPv6 segment routing) path programming, service level mapping, and gport identifier slice identification, differentiated forwarding and service level identification of cross-domain traffic are achieved, completing the forwarding and mapping configuration of the slice policy. The specific steps are as follows:

[0066] SRv6 path programming: The CTC8180 chip SDK's ctcs_srv6_add_my_sid() interface is called to configure segment identifiers (SIDs), supporting SID configuration in three formats: Traditional SID, uSID, and gSID. Combined with the nexthop add srv6 command, the next-hop node corresponding to each SID is specified to construct the end-to-end SRv6 traffic engineering (TE) policy forwarding path, realizing cross-domain traffic path planning and precise forwarding.

[0067] Service level mapping: The CTC8180 chip SDK's ctcs_acl_add_entry() interface is called to configure the Access Control List (ACL). The ACL rules are used to match target service flows (matching dimensions include source IP address, destination IP address, service port number, protocol type, etc.). Based on the QoS Table-map, mapping rules are established to map the external Differential Service Code Point (DSCP) values ​​of the matched service flows to the device's internal priority and color, forming a one-to-one correspondence between service level and forwarding priority, ensuring priority forwarding for primary services (such as industrial control, high-definition video, etc.).

[0068] Slice identification: The CTC8180 chip SDK's ctcs_set_internal_port() interface is called to assign a unique global port number (gport) to each FlexE Client logical port, using gport as the core identifier of the slice. When the device receives a packet, it identifies the corresponding FlexE Client logical port by parsing the gport information carried in the packet, thereby determining the network slice to which the packet belongs. This enables the forwarding and mapping configuration of the slice policy, achieving accurate packet identification and targeted forwarding based on the slice logical port, and completing the closed-loop management of the entire slice service process.

[0069] S4. Based on the slice strategy, forwarding and mapping configuration adopts TWAMP Light performance measurement, Telemetry data collection and BFD fast detection to monitor slice link performance and collect status data in real time and quickly detect faults, triggering alarms to support optimization and recovery;

[0070] Specifically, in S4, the link performance and faults of the real-time monitoring slice service are quickly detected using the Two-Way Active Measurement Protocol (TWAMP) Light performance measurement, Telemetry data acquisition, and Two-Way Forwarding Detection Protocol (BFD), as follows;

[0071] TWAMP Light performance measurement: In the forwarding nodes (switches / routers) of the network slice, the ctcs_acl_add_entry() interface of the CTC8180 chip SDK is called to configure ACL rules. TWAMP Light measurement packets with destination UDP port 5000 are used as matching objects to filter non-measurement packets and reduce invalid data transmission. The ctcs_packet_rx_register() interface provided by the forwarding chip is called to register the TWAMP packet receiving callback function. When the forwarding node receives a TWAMP Light packet that matches the ACL rules, the callback function is triggered to send the packet to the CPU for priority processing to avoid the packet being dropped in the forwarding plane.

[0072] Telemetry data acquisition: A data acquisition channel is built based on the in-band network telemetry (INT) mechanism. The INT acquisition rules of each network node on the forwarding path are used to collect path status data in real time. The acquisition dimensions include, but are not limited to, switch ID, port traffic, queue congestion level, packet forwarding time, etc. The collected status data is pushed to the remote analysis platform through a designated reporting channel to provide data support for slice link optimization, resource scheduling and fault prediction.

[0073] BFD Fast Detection: This feature performs full-process detection of slice services. A `ctc_oam_key_t` structure is defined to store key identification information of the BFD session (including session type, encapsulation method, associated service identifier, etc.), and a `ctc_oam_lmep_cfg_t` structure is defined to configure the BFD session's operating parameters (including detection cycle, timeout threshold, message encapsulation format, etc.). The `ctcs_oam_add_lmep()` API of the CTC8180 chip SDK is called to instantiate the BFD session based on the configuration information of the above two structures. This BFD session supports multiple encapsulation types such as IP, Label Switched Path (LSP), and Virtual Circuit Connection Verification (VCCV), with a detection cycle down to the millisecond level. When a link in the slice service experiences interruption, sudden latency changes, or other faults, the BFD session quickly detects and triggers fault alarms, providing support for rapid fault location and recovery.

[0074] S5. Set up resource dynamic adjustment strategy and path switching strategy. Trigger resource dynamic adjustment and path switching by detecting fault results. Through resource dynamic adjustment strategy, path switching strategy, strategy linkage and confirmation feedback results, form a closed-loop control of "perception-decision-execution-confirmation".

[0075] Specifically, in S5, the dynamic adjustment of resources, path switching, strategy linkage, and confirmation feedback results are as follows:

[0076] Dynamic resource adjustment: The status awareness and acquisition submodule pushes the collected performance data such as link congestion status and bandwidth utilization to the dynamic decision-making unit. When slice link congestion is detected (queue congestion level exceeds the preset threshold) or bandwidth demand changes (actual bandwidth utilization is continuously higher / lower than the configured threshold), the dynamic decision-making unit automatically generates resource adjustment instructions. It calls the ctcs_flexe_client_add_cal_slot() interface of the CTC8180 chip SDK to add time slot resources to the slice to expand bandwidth, or calls the ctcs_flexe_client_remove_cal_slot() interface to reduce slice time slot resources to shrink bandwidth, ensuring that slice resources are accurately matched with business needs.

[0077] Path switching: When the BFD detection unit detects a fault in the primary SRv6 TE path (such as link interruption or excessive latency), it immediately triggers the control plane path recalculation process. The control plane replans the backup path based on the remaining available link resources. It updates the next-hop mapping relationship of the segment identifier (SID) by calling the ctcs_srv6_update_my_sid() interface, or directly updates the device forwarding table entries, so as to seamlessly switch the slice service traffic from the primary path to the backup path and reduce the duration of the impact of the fault on the service.

[0078] Policy linkage and confirmation: After resource adjustment or path switching is completed, the policy execution result is fed back through two channels: firstly, through the NETCONF protocol. <rpc-reply>The system first feeds back the configuration execution status (success / failure, adjusted resource parameters, etc.) to the upper-level controller; secondly, it reports the adjusted slice performance data (such as bandwidth after expansion, path latency after switching, etc.) to the remote analysis platform through the Telemetry channel; after receiving the feedback information, the upper-level controller or analysis platform completes the policy execution confirmation, forming a complete closed-loop control of "perception-decision-execution-confirmation".

[0079] S6. The steps of integrating S1-S5 are completed through multi-chip image support, kernel-mode driver and CLI integration to complete system driver and integration configuration, and realize network slice configuration and response.

[0080] Specifically, in S6, the integration of steps S1-S5 is achieved through multi-chip image support, kernel-mode driver, and CLI integration to complete the system driver and integration configuration, as detailed below;

[0081] Multi-chip image support: A unified compilation system framework is built, and the CHIPNAME variable is configured as the chip model identifier through the Makefile script; during the compilation process, the SDK interface definition, driver and hardware adaptation parameters of the target chip are dynamically matched based on the value of the CHIPNAME variable (such as "CTC8180" "CTC8190" etc.); the hardware difference code between different chips is shielded through the conditional compilation mechanism, so as to achieve compatible deployment of multiple chips with the same system image and reduce the system maintenance cost in multi-chip scenarios;

[0082] Kernel-mode driver: Based on the Linux kernel driver development specification, the chip access layer (DAL) driver code is written and compiled to generate the dal.ko kernel module. This kernel module integrates the low-level hardware access interface of the CTC8180 chip, including core functions such as register operation, interrupt handling, and resource scheduling, providing kernel-level chip access capabilities for the upper-layer SDK. The dal.ko module is loaded through the insmod or modprobe commands to complete the adaptation and mounting of the driver and kernel, ensuring that upper-layer applications can access chip hardware resources through standardized interfaces.

[0083] CLI Integration: Establishes a communication architecture between the ctc-shell client and the SDK Server; the ctc-shell client provides a command-line interface, supporting operations and maintenance personnel to input commands such as slice policy configuration, status query, and fault recovery; the SDK Server, as the server, receives command requests from the ctc-shell client and, through interaction with the kernel-mode dal.ko driver module, converts the commands into chip-recognizable operations; it also supports remote login (such as SSH protocol) to access the ctc-shell client, enabling remote configuration and operation status query of remote CTC8180 chip devices.

[0084] The specific embodiments of the present invention are described in detail below with reference to the technical solution and accompanying drawings:

[0085] This invention is implemented on an air-sea cross-domain gateway device with the CTC8180 chip as the core hardware. The gateway achieves the collaborative orchestration of the underlying discrete hardware functions by executing the method described in this invention ("slice policy reception and parsing → hardware resource isolation and instantiation → collaborative forwarding mapping configuration → full-dimensional state perception → dynamic response closed-loop control" progressive process). Thus, on a hardware platform that does not have native advanced slicing functions, a fully functional logical network slice for air-sea cross-domain scenarios can be constructed.

[0086] (1) Receiving and parsing the slicing strategy

[0087] The embodiments of the present invention support two parallel configuration paths to adapt to different scenarios such as automated deployment and manual operation and maintenance;

[0088] Automated configuration via the NETCONF interface:

[0089] The upper-layer network controller interacts with the gateway device in this embodiment via the NETCONF protocol; all slice-related configuration items are structurally described using a predefined YANG data model; the controller conforms to the RFC 6241 standard, establishes a secure session (NETCONF over SSH), and sends... <edit-config>The gateway's candidate configuration dataset is edited using XML-formatted RPC messages.

[0090] Manual or scripted configuration via CLI interface:

[0091] Network maintenance personnel can log in to the device directly via the console or SSH and configure it using the series of command-line interfaces (CLI) provided in this embodiment; they can also configure it via flexe group create.<GROUP_ID> Follow these instructions to gradually complete the creation of slices and strategy configuration;

[0092] (2) Instantiation of hardware resource isolation

[0093] To achieve strict physical layer isolation between network slices, the core of this embodiment lies in the collaborative orchestration of the CTC8180 chip's Flexible Ethernet (FlexE) function, which allocates exclusive hardware resources at the physical layer for each slice.

[0094] First, on the physical port used to carry cross-domain services, the ctcs_flexe_serdes_enable() API provided by the SDK is called to enable its serializer / deserializer (SerDes) to work in FlexE mode. Then, ctcs_flexe_group_create() is called to create a FlexE Group resource pool, and one or more FlexE-enabled physical ports are added to the group through ctcs_flexe_group_add_phy(), thereby aggregating their bandwidth and forming a unified timeslot resource pool.

[0095] Next, for each logical slice that needs to be created, the control plane calls the core client creation primitive, namely the ctcs_flexe_add_client() API, to instantiate a FlexE Client within the FlexE Group; each Client instance is logically represented as an independent port, representing a network slice.

[0096] int32 ctcs_flexe_add_client(uint8 ldev, uint32 client_id, ctc_flexe_client_t* p_client);

[0097] Once a Client instance is created, it is merely a logical concept. To enable it to participate in actual packet forwarding, it must be bound to a globally unique hardware port identifier (gport). This process is accomplished by calling the ctcs_set_internal_port() API. The core of this API is to populate the ctc_internal_port_assign_para_s data structure, thereby establishing a precise mapping between the logical Client and the physical forwarding plane.

[0098] The core data structure is defined as follows:

[0099] struct ctc_internal_port_assign_para_s

[0100] {

[0101] ctc_internal_port_type_t type; / / Internal port type, here we select forwarding type.

[0102] uint8 gchip; / / Global chip ID

[0103] uint8 slice_id; / / Slice ID

[0104] uint32 fwd_gport; / / [Output] The allocated gport handle

[0105] uint32 nhid; / / Next hop information

[0106] };

[0107] typedef struct ctc_internal_port_assign_para_s ctc_internal_port_assign_para_t;

[0108] After binding is complete, the logical slice has a hardware handle (fwd_gport) that can be referenced by forwarding tables, ACL policies, and QoS policies. Then, by calling the ctcs_flexe_client_add_cal_slot() API, one or more time slots are precisely allocated to the client from the Group resource pool. The number of time slots allocated strictly determines the bandwidth limit of the slice, thereby achieving hardware-level bandwidth guarantee and physical isolation.

[0109] Finally, APIs such as ctcs_l3if_create() and ctcs_l3if_set_property() are called to create a Layer 3 interface for the gport bound to the Client and associate it with a specific Virtual Router Forwarder (VRF) instance, thereby achieving isolation of the routing plane.

[0110] (3) Cooperative strategy forwarding and mapping

[0111] To address specific challenges across air and sea domains, this embodiment collaboratively orchestrates multiple functions of the chip, including QoS, ACL, and SRv6.

[0112] Asymmetric QoS strategy to address bandwidth cliff: For the egress direction in the ocean domain, configure a refined multi-level QoS model; use ctcs_acl_add_entry() to configure ACL rules and identify different service flows; use commands such as qos table-map-id to map the Differential Service Code Point (DSCP) values ​​of packets to internal chip priority and color; use APIs such as ctcs_qos_create_sched_group() and ctcs_qos_set_shape() to configure strict traffic shaping and priority-based queue scheduling for this egress, ensuring that the total rate does not exceed the link capacity and that critical services are prioritized for forwarding.

[0113] SRv6-based deterministic path construction: To ensure end-to-end latency for critical services, this embodiment uses SRv6TE for path programming; the local SID is configured through ctcs_srv6_add_my_sid(), and a forwarding policy containing a specified Segment List is constructed through commands such as nexthop add srv6, guiding service traffic to be transmitted along a preset path;

[0114] (4) State perception and dynamic response

[0115] To adapt to the highly dynamic characteristics of air-sea links, this embodiment constructs a closed-loop response mechanism from hardware status awareness to dynamic adjustment of the control plane. By instantiating a hardware-level BFD session within the chip, millisecond-level high-frequency detection of link connectivity is achieved. In addition, to achieve more refined performance and status monitoring, this embodiment integrates the Two-Way Active Measurement Protocol (TWAMP) Light and in-band network telemetry functions.

[0116] The following is a specific configuration example of the TWAMP Light and Telemetry protocol, where all commands are CLI configuration sequences for the CTC8180 chip:

[0117] TWAMP Light receiver configuration:

[0118] # 1. Basic Interface and MPLS VPN Configuration

[0119] MAC address enabled (port 0x0002)

[0120] port 0x0002 port-en enable

[0121] l3if create ifid 1 type phy-if gport 0x0002

[0122] l3if ifid 1 mpls-property mpls-en value 1

[0123] l3if router-mac 001f.feaf.0000

[0124] nexthop add mpls 3 dsnh-offset 3 push fwd vpls-port 300 ...

[0125] mpls l2vpn-pw add 20 vpls 4096 pwid 300 vpls-port-type encapsulation-mode raw

[0126] # 2. Configure ACLs to precisely match TWAMP measurement packets and send them to the OAM processing engine.

[0127] port 0x0002 acl-property priority 0 direction ingress acl-en enabletcam-lkup-type 13

[0128] acl create group 0 priority 0 direction ingress gport 0x0002

[0129] acl add group 0 entry 1 ipv4-entry field-mode

[0130] acl entry 1 add key-field ip-da 12.12.12.2 255.255.255.255

[0131] acl entry 1 add key-field l4-type 2

[0132] acl entry 1 add key-field l4-dst-port 5000 0xffff

[0133] acl entry 1 add action-field oam twamp dest-gchip 0 lmep-index 0x2packet-offset 64

[0134] acl install group 0

[0135] # 3. Configure the return path and session parameters for reflected messages

[0136] nexthop add iloop 106 lpbk-lport 0x8004 ...

[0137] nexthop add misc replace-flex-hdr 110 ...

[0138] npm session 18 cfg twamp-lite mode 2 offset-adjust-en nhid 110 enable

[0139] Telemetry Sink node configuration:

[0140] # 1. Basic VLAN and Layer 3 Interface Initialization

[0141] vlan create vlan 10 default-entry

[0142] MAC address enabled on port 0x0001 ...

[0143] l3if create ifid 1 type phy-if gport 0x0001

[0144] l3if router-mac 001f.feaf.adfb

[0145] # 2. Configure ACLs to match service flows that require telemetry.

[0146] port 0x0001 acl-property priority 0 direction ingress acl-en enable tcam-lkup-type 13

[0147] acl create group 0 direction ingress lchip 0 none

[0148] acl add group 0 entry 0 ipv4-entry field-mode

[0149] acl entry 0 add key-field ip-da 2.2.2.100 255.255.255.255

[0150] acl entry 0 add action-field int-log 30 4

[0151] acl install group 0

[0152] # 3. Enable the INT function and configure the telemetry session

[0153] dtel property int-mode probe-marker 0xaabbccdd11223344

[0154] dtel int int-en value 1

[0155] dtel property switch-id 0x00abcdef

[0156] dtel int session-id 30 log-en log-id 3 log-percent 15 nhid 100

[0157] When BFD, TWAMP, or Telemetry mechanisms detect link failures, performance degradation, or bandwidth changes, the control plane is automatically triggered. For example, a BFD session state changing to Down will trigger the routing protocol to reconverge and switch traffic to a backup path. When a link bandwidth change is detected, the ctcs_flexe_client_add_cal_slot() or ctcs_flexe_client_remove_cal_slot() API can be automatically called to dynamically expand or shrink the time slot resources of the slice, thus forming a complete closed loop of "perception-decision-execution-confirmation" to ensure the continuity and reliability of services in highly dynamic environments.

[0158] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0159] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for configuring and responding to cross-domain air and sea networks based on the CTC8180 chip, characterized in that, The specific process is as follows: S1. Initiate slice configuration request, standardize the slice configuration command in a unified format, configure and connect to NETCONF and CLI channels in parallel, convert the configuration command into API call command that can be recognized by CTC8180 chip SDK and send it, realize slice strategy reception and execution; S2. With the help of the CTC8180 chip SDK, API call instructions can be recognized. Based on FlexE technology, by creating a FlexE Group resource pool and FlexE Client logical port, binding the L3 interface and configuring VRF policy, the FlexEClient logical port of the bound business is obtained, which is used to realize the isolation of slice physical layer resources and business deployment. S3. Based on the CTC8180 chip SDK, it can identify API call commands and the FlexE Client logical port bound to the service. Combined with SRv6 path programming, service level mapping and slice identification through gport, it completes the forwarding and mapping configuration of slice policy. S4. Based on the slice strategy, forwarding and mapping configuration adopts TWAMP Light performance measurement, Telemetry data collection and BFD fast detection to monitor slice link performance and collect status data in real time and quickly detect faults, triggering alarms to support optimization and recovery; S5. Set up resource dynamic adjustment strategy and path switching strategy. Trigger resource dynamic adjustment and path switching by detecting fault results. Through resource dynamic adjustment strategy, path switching strategy, strategy linkage and confirmation feedback results, form a closed-loop control of "perception-decision-execution-confirmation". S6. The steps of integrating S1-S5 are completed through multi-chip image support, kernel-mode driver and CLI integration to complete system driver and integration configuration, and realize network slice configuration and response.

2. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In step S1, the configuration instructions are converted into API instructions recognizable by the CTC8180 chip SDK and sent. The configuration includes the configuration of the NETCONF interface, the CLI interface, and the adaptation mechanism, as detailed below: NETCONF Interface Configuration: When receiving configuration commands using the NETCONF interface, the slicing strategy data structure is defined based on the standardized YANG data model, and the configuration commands are sent out through Remote Procedure Call (RPC) messages in Extensible Markup Language format as the transport carrier. Its configuration process includes establishing a session, locking the configuration set, editing the candidate dataset, submitting and unlocking the running dataset; CLI Interface Configuration: When receiving slicing strategy configuration instructions through the CLI interface, it provides a command-line instruction set for operation and maintenance scenarios, supporting operation and maintenance personnel to write script files containing multiple command-line instructions, and to achieve batch deployment of slicing strategies and rapid fault recovery in abnormal scenarios through scripting. Adaptation mechanism: The slicing strategy configuration instructions received by the NETCONF interface and CLI interface are standardized and processed in a unified format. The configuration instructions of both paths are converted into application programming interface (API) call instructions of the underlying CTC8180 chip software development kit, and the converted API call instructions are sent to the CTC8180 chip.

3. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In step S2, the logical port of the FlexE Client bound to the business is obtained. The relevant configuration of the port includes FlexE function initialization, FlexE Group creation, Client slice instantiation, and business interface binding, as detailed below: FlexE Function Initialization: Call the ctcs_flexe_serdes_enable() interface provided by the CTC8180 chip SDK to specify the FlexE working mode of the serializer / deserializer and complete the underlying hardware initialization of the FlexE function. FlexE Group Creation: The ctcs_flexe_group_create() interface is called to create a FlexE Group resource pool, which is used to aggregate bandwidth resources from multiple physical ports; then, the specified physical ports are added to the FlexE Group through the ctcs_flexe_group_add_phy() interface, forming a dynamically allocable shared bandwidth resource pool. Client slice instantiation: The ctcs_flexe_client_create() interface is called to create a FlexE Client logical port. Each FlexE Client logical port represents a network slice, which serves as a resource carrier entity at the physical layer. The ctcs_flexe_client_add_cal_slot() interface is used to dynamically allocate dedicated time slots for each FlexE Client from the FlexE Group resource pool. The number of time slots allocated is positively correlated with the bandwidth requirements of the slice, thereby achieving bandwidth isolation and precise control between different slices. Service Interface Binding: The created FlexE Client logical port is bound to a Layer 3 interface. An L3 interface is created by calling the ctcs_l3if_create() interface, and then the virtual route forwarding attribute is configured for the L3 interface by the ctcs_l3if_set_property() interface to achieve route isolation for the slice. It also supports the configuration of virtual LAN isolation policy and quality of service priority scheduling policy services. That is, a hardware-isolated FlexE Client logical port is created for each network slice, and the port is bound to the L3 interface and the VRF / VLAN / QoS basic service policy to complete the entire process of slice implementation from physical layer resource isolation to service policy deployment.

4. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In S3, by combining SRv6 path programming, service level mapping, and gport identifier slice identification, differentiated forwarding and service level identification of cross-domain traffic are achieved, completing the forwarding and mapping configuration of the slice policy, as follows: SRv6 path programming: The CTC8180 chip SDK's ctcs_srv6_add_my_sid() interface is called to configure segment identifiers, supporting SID configuration in three formats: Traditional SID, uSID, and gSID. Combined with the nexthop add srv6 command, the next-hop node corresponding to each SID is specified to construct the forwarding path of the end-to-end SRv6 traffic engineering strategy, realizing path planning and precise forwarding of cross-domain traffic. Service level mapping: Call the ctcs_acl_add_entry() interface of the CTC8180 chip SDK to configure the access control list and match the target service flow through ACL rules; Based on the QoS Table-map, mapping rules are established to map the external differential service code point values ​​of the matched service flows to the internal priority and color of the device, forming a one-to-one correspondence between service level and forwarding priority; Slice identification: The CTC8180 chip SDK's ctcs_set_internal_port() interface is called to assign a unique global port number to each FlexEClient logical port, using gport as the core identifier of the slice; when the device receives a packet, it identifies the corresponding FlexE Client logical port by parsing the gport information carried in the packet, thereby determining the network slice to which the packet belongs, realizing the forwarding and mapping configuration of the slice policy, and completing the closed-loop management of the entire slice service process.

5. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In S4, TWAMP Light performance measurement, Telemetry data acquisition, and BFD rapid detection are used to monitor slice link performance in real time, collect status data, and quickly detect faults, triggering alarms to support optimization and recovery, as detailed below: TWAMP Light performance measurement: Configure ACL rules in the forwarding nodes of the network slice, use TWAMP Light measurement packets with destination UDP port 5000 as the matching object, filter non-measurement packets to reduce invalid data transmission; call the ctcs_packet_rx_register() interface provided by the forwarding chip to register the TWAMP packet receiving callback function. When the forwarding node receives a TWAMP Light packet that matches the ACL rules, trigger the callback function to send the packet to the CPU for processing first, avoiding the packet being dropped in the forwarding plane; Telemetry data acquisition: A data acquisition channel is built based on the in-band network telemetry mechanism. By configuring the INT acquisition rules of each network node on the slice forwarding path, path status data is collected in real time. The collected status data is pushed to the remote analysis platform through the specified reporting channel to provide data support for slice link optimization, resource scheduling and fault prediction. BFD Fast Detection: Detects the entire process of slice operations. Defines a ctc_oam_key_t structure to store key identification information of the BFD session, and defines a ctc_oam_lmep_cfg_t structure to configure the running parameters of the BFD session; calls the ctcs_oam_add_lmep() API of the CTC8180 chip SDK to instantiate the BFD session based on the configuration information of the two structures; This BFD session supports multiple encapsulation types, including IP, tag switching path, and virtual circuit connection verification, with a detection cycle down to the millisecond level. When a slice link experiences an interruption or a sudden change in latency, the BFD session can quickly detect and trigger a fault alarm, providing support for rapid fault location and recovery.

6. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In S5, the resource dynamic adjustment strategy, path switching strategy, strategy linkage, and confirmation feedback results are implemented as follows: Dynamic resource adjustment strategy: The status awareness and acquisition submodule pushes the collected link congestion status and bandwidth utilization performance data to the dynamic decision-making unit; when slice link congestion or bandwidth demand changes are detected, the dynamic decision-making unit automatically generates resource adjustment instructions, calls the ctcs_flexe_client_add_cal_slot() interface of the CTC8180 chip SDK to add time slot resources to the slice to expand bandwidth, or calls the ctcs_flexe_client_remove_cal_slot() interface to reduce slice time slot resources to shrink bandwidth, ensuring that slice resources are accurately matched with business needs; Path switching strategy: When the BFD detection unit detects a failure in the primary SRv6 TE path, it immediately triggers the control plane path recalculation process. The control plane replans the backup path based on the remaining link resources, updates the next-hop mapping relationship of the segment identifier by calling the ctcs_srv6_update_my_sid() interface, or directly updates the device forwarding table entries, seamlessly switching the slice service traffic from the primary path to the backup path, reducing the duration of the failure's impact on services. Policy linkage and confirmation: After resource adjustment or path switching is completed, the policy execution result is fed back through two channels: firstly, through the NETCONF protocol. <rpc-reply> The system first feeds back the configuration execution status to the upper-level controller; secondly, it reports the adjusted slice performance data to the remote analysis platform through the Telemetry channel; after receiving the feedback information, the upper-level controller or analysis platform completes the policy execution confirmation, forming a complete closed-loop control of "perception-decision-execution-confirmation".

7. The air-sea cross-domain network slicing configuration and response method based on the CTC8180 chip according to claim 1, characterized in that, In step S6, the integration of steps S1-S5 is achieved through multi-chip image support, kernel-mode driver, and CLI integration, completing the system driver and integration configuration as follows: Multi-chip image support: Build a unified compilation system framework and configure the CHIPNAME variable as the chip model identifier through Makefile script; in the compilation process, dynamically match the SDK interface definition, driver and hardware adaptation parameters of the target chip based on the value of the CHIPNAME variable; shield the hardware difference code between different chips through conditional compilation mechanism, realize the compatible deployment of the same system image for multiple chips, and reduce the system maintenance cost in multi-chip scenarios; Kernel-mode driver: Based on the Linux kernel driver development specification, chip access layer driver code is written and compiled to generate the dal.ko kernel module. This kernel module integrates the low-level hardware access interface of the CTC8180 chip, including register operations, interrupt handling, and resource scheduling core functions, providing kernel-level chip access capabilities for the upper-layer SDK. The dal.ko module is loaded through the insmod or modprobe commands to complete the driver and kernel adaptation and ensure that upper-layer applications access chip hardware resources through standardized interfaces. CLI Integration: Establishes a communication architecture between the ctc-shell client and the SDK Server; the ctc-shell client provides a command-line interface, supporting operations and maintenance personnel to input slicing strategy configuration, status query, and fault recovery commands; the SDK Server, acting as a server, receives command requests from the ctc-shell client and, through interaction with the kernel-mode dal.ko driver module, converts the commands into chip-recognizable operations; it also supports remote login access to the ctc-shell client, enabling remote configuration and operation status query of remote CTC8180 chip devices.

Images