Configuration method and system of software defined network

Abstract

The invention relates to the technical field of software-defined network configuration, in particular to a software-defined network configuration method and system, comprising: receiving a user service request, and generating service features and service quality requirements through natural language processing and feature extraction, generating a network slicing strategy containing a binding relationship between a resource reservation parameter and a path based on a service level agreement mapping rule and network topology state information, and converting the network slicing strategy into an equipment-independent general configuration instruction based on a unified data model, and compiling the general configuration instruction into an equipment special instruction which can be executed by equipment of different manufacturers, issuing the equipment special instruction to target network equipment through a southbound interface of the SDN controller, receiving configuration confirmation information returned by the equipment, and verifying the configuration confirmation information so as to ensure that the equipment runs according to the service quality requirement. According to the invention, business demand analysis standardization, resource allocation refinement, equipment instruction unification and configuration execution verifiability can be realized, and the controllability and reliability of the SDN network are improved.

Description

A configuration method and system for software-defined networks Technical Field

[0001] This invention relates to the field of software-defined network configuration technology, and specifically to a software-defined network configuration method and system. Background Technology

[0002] With the diversification and refinement of network services, Software-Defined Networking (SDN) has gradually become a key technology for building flexible network architectures and supporting differentiated service needs. Faced with the simultaneous existence of multiple services such as high-definition video conferencing, real-time voice communication, and cloud backup, operational networks need to dynamically adjust network resources according to service type and quality-of-service (QoS) requirements to meet the diverse bandwidth, latency, and reliability needs of different services. By introducing network slicing mechanisms, unified underlying network resources can be divided into multiple virtual networks with independent QoS attributes as needed, enabling flexible resource allocation, controllable policies, and fine-grained scheduling based on services, providing higher service quality for complex business scenarios.

[0003] Existing software-defined network (SDN) configuration solutions still have significant shortcomings in key areas such as service parsing, resource mapping, and device configuration. On the one hand, traditional solutions often rely on manual parsing of service requirements, lacking a unified, structured way of expressing service requests. This leads to inaccurate extraction of service characteristics and difficulty in achieving a rigorous match between service requirements and network resources. On the other hand, existing network slicing policy generation processes typically lack precise bandwidth reservation and latency cap quantification mechanisms, resulting in slicing policies failing to provide predictable quality of service (QoS) guarantees. Furthermore, at the device configuration level, existing methods struggle to achieve unified configuration command abstraction in multi-vendor, multi-model device environments. The configuration process often requires tedious manual adjustments based on device characteristics, leading to a large workload, high error rates, and a lack of verifiable mechanisms. Especially after configuration distribution, most existing solutions cannot automatically verify the actual operating status of devices, failing to ensure that devices strictly adhere to service QoS requirements, thus posing risks to network stability and reliability. Summary of the Invention

[0004] The purpose of this invention is to provide a configuration method and system for software-defined networks to solve the problems of non-standard parsing of service requests, inaccurate generation of network slicing strategies, inability to uniformly abstract device configurations, and lack of verification mechanisms in configuration execution in the prior art.

[0005] To address the aforementioned technical problems, the present invention specifically provides the following technical solution: a software-defined network configuration method, comprising the following steps: S1: receiving a user service request and extracting service characteristics and quality of service requirements from the service request; S2: generating a network slicing strategy with a specific resource guarantee level based on the service characteristics, the quality of service requirements, and real-time collected network topology status information; S3: generating device-independent general configuration instructions according to the network slicing strategy and pre-stored device capability information, wherein the general configuration instructions include a parameter set for guaranteeing the quality of service requirements; S4: dynamically compiling the general configuration instructions into device-specific instructions corresponding to the target network device type, and issuing them to the target network device for execution through an SDN controller, so that the target network device operates according to the quality of service requirements.

[0006] As a preferred embodiment of the present invention, step S1 includes: S11: receiving a user service request, parsing the user service request, and generating structured service request data containing fields such as service type, source and destination addresses, bandwidth parameters, latency parameters, and service priority; S12: identifying service characteristics and service quality requirements from the structured service request data, wherein the service characteristics include service type and service priority, and the service quality requirements include bandwidth parameters and latency parameters; S13: classifying the service characteristics based on a preset mapping relationship between service types and feature rules, and generating a service type identifier with a deterministic service level label; S14: quantifying the specific values ​​of the bandwidth parameters and the latency parameters according to the service type identifier and the service quality requirements, and generating a standardized set of service quality requirement indicators.

[0007] As a preferred embodiment of the present invention, the parsing of the user service request is completed by a natural language processing module. The natural language processing module extracts key information from the text-based user service request and fills it into a predefined service request template to generate the structured service request data.

[0008] As a preferred embodiment of the present invention, the identification of business characteristics and service quality requirements is achieved through a feature extraction engine. The feature extraction engine reads and encapsulates the business characteristics and service quality requirements from the corresponding fields of the structured business request data based on a pre-set business characteristic rule library.

[0009] As a preferred embodiment of the present invention, S2 includes: S21: Based on the service characteristics and the quality of service requirements, by querying the preset service level agreement mapping rules, determining the specific resource guarantee level, and generating a key resource requirement description including bandwidth reservation value, latency upper limit value, and isolation type; S22: Combining the key resource requirement description and the network topology status information, using the path calculation engine to execute the constrained shortest path first algorithm to calculate one or more candidate paths that conform to the key resource requirement description, and generating a path resource allocation scheme including path identifier, bandwidth allocation details, and link latency indicators; S23: Integrating the specific resource guarantee level, the key resource requirement description, and the path resource allocation scheme to construct a complete network slicing strategy including a unique slice identifier, resource reservation parameters, and path binding relationships.

[0010] As a preferred embodiment of the present invention, the preset service level agreement mapping rules are stored in a policy database, and the policy database associates and maps different service types with corresponding specific resource guarantee levels, bandwidth reservation values, latency limits and isolation types.

[0011] As a preferred embodiment of the present invention, step S3 includes: S31: parsing the network slicing strategy, extracting the unique slice identifier, resource reservation parameters, and path binding relationships, and converting them into a set of slice configuration elements independent of specific devices; S32: querying the device capability information, and converting the slice configuration elements into an intermediate instruction set conforming to the standard data model specification based on the device manufacturer, model, and supported protocols recorded in the device capability information; S33: integrating the intermediate instruction set, injecting a parameter set for ensuring the quality of service requirements, and encapsulating it to generate a device-independent universal configuration instruction that can be uniformly identified by devices from different manufacturers.

[0012] As a preferred embodiment of the present invention, the network slicing strategy is implemented by a policy parsing engine. The policy parsing engine extracts the unique slice identifier, resource reservation parameters and path binding relationship from the network slicing strategy according to predefined policy syntax rules, and outputs them as structured slice configuration elements.

[0013] As a preferred embodiment of the present invention, step S4 includes: S41: Selecting a corresponding protocol adapter from the protocol adapter library according to the device type of the target network device, and loading an instruction compilation template that matches the device type; S42: Using the protocol adapter to parse the general configuration instruction, and converting the general configuration instruction into a device-specific instruction that the target network device can recognize and execute according to the instruction compilation template; S43: Sending the device-specific instruction to the target network device through the southbound interface of the SDN controller, and receiving configuration confirmation information returned by the target network device to confirm that the target network device is operating according to the quality of service requirements.

[0014] A configuration system for a software-defined network (SDN) is provided to implement the aforementioned configuration method for a SDN. The system includes the following modules: a service request access module for receiving user service requests and submitting them to a natural language processing (NLP) module for subsequent parsing; a NLP module for parsing the user service requests provided by the service request access module, generating structured service request data containing fields for service type, source and destination addresses, bandwidth parameters, latency parameters, and service priority, and providing this structured service request data to a subsequent service feature analysis unit; and a service type classification module for classifying service types based on the service type fields in the structured service request data. The segment and business priority fields classify business characteristics according to the preset mapping relationship between business types and feature rules, generating business type identifiers with deterministic service level labels; the service quality requirement quantification module is used to standardize the bandwidth parameters and generate specific bandwidth values ​​based on the business type identifier and the bandwidth and latency parameters in the structured business request data, and to impose millisecond-level precision constraints on the latency parameters and generate specific latency values, thereby forming a standardized set of service quality requirement indicators; the business level agreement query module is used to query preset business level agreements stored in the strategy database based on business characteristics and the standardized set of service quality requirement indicators. The system defines mapping rules to determine specific resource guarantee levels and generates key resource requirement descriptions including bandwidth reservation values, latency limits, and isolation types. A network slicing strategy construction module combines the key resource requirement descriptions with path resource allocation schemes generated based on real-time collected network topology status information. This integrates specific resource guarantee levels, key resource requirement descriptions, and path resource allocation schemes to construct a network slicing strategy containing unique slice identifiers, resource reservation parameters, and path binding relationships. A model-driven abstraction module extracts the unique slice identifiers and resource reservation parameters from the network slicing strategy based on the device manufacturer, model, and supported protocols recorded in pre-stored device capability information. The path binding relationship is transformed into a slice configuration element independent of specific devices, and the slice configuration element is mapped to an intermediate instruction set according to the standard data model specification; the instruction encapsulation module is used to encapsulate the intermediate instruction set generated by the model-driven abstraction module, inject a parameter set to ensure service quality requirements, and generate device-independent general configuration instructions based on the intermediate instruction set generated by the model-driven abstraction module; the protocol adapter management module is used to select the protocol adapter corresponding to the device manufacturer and model from the protocol adapter library according to the device type of the target network device, load the instruction compilation template matching the target network device type, and provide the protocol adapter and instruction compilation template to the instruction parsing module;The instruction parsing module calls the protocol adapter to parse the syntax of the general configuration instructions generated by the instruction encapsulation module. Based on the instruction compilation template, it maps and populates each configuration item in the general configuration instructions (based on the standard data model) into device-specific instructions that the target network device can recognize and execute. The southbound interface module sends the device-specific instructions generated by the instruction parsing module to the target network device through the southbound interface of the SDN controller and receives configuration confirmation information returned by the target network device. The alarm module, upon receiving the configuration confirmation information, compares the device operating parameters fed back in the confirmation information with the set of parameters included in the general configuration instructions to ensure quality of service requirements. If the comparison results are inconsistent, it generates alarm information or triggers a reconfiguration process, thereby ensuring that the target network device operates according to quality of service requirements.

[0015] Compared with existing technologies, this invention has the following advantages: This invention constructs a complete and quantifiable business requirement parsing system through a business request access module, a natural language processing module, a business type classification module, and a service quality requirement quantification module. This enables accurate identification and structured expression of business types, bandwidth parameters, latency parameters, and business priorities. Based on this, the service level agreement query module generates key resource requirement descriptions according to standardized service level agreement mapping rules. This ensures that the network slicing strategy has clearly defined bandwidth reservation values, latency limits, and isolation types, thereby significantly improving the accurate matching capability of network service quality requirements. This achieves precise alignment between business requirements and network resource characteristics, effectively guaranteeing the differentiated service quality of different services within the network.

[0016] This invention establishes a top-down, device-independent configuration generation chain through a policy parsing engine, a model-driven abstraction module, an instruction encapsulation module, and a protocol adapter management module. Sliced ​​configuration elements are converted into general configuration instructions via an intermediate instruction set based on a unified YANG model. Subsequently, a protocol adapter with a syntax parser and rule engine generates device-specific instructions conforming to the instruction formats specific to each device manufacturer and model. This structure achieves the technical effect of "unified upper-layer policies and transparent differences between lower-layer devices," eliminating the need for manual adjustments to network configuration for each device, significantly reducing network configuration complexity, and improving device compatibility and the maintainability of large-scale heterogeneous networks.

[0017] This invention reliably sends device-specific commands to the target network device via a southbound interface module. After the device returns configuration confirmation information, the alarm module performs configuration verification. The verification process compares the device's operating parameters field-by-field with the parameter set used to ensure quality of service (QoS) requirements. This allows for timely identification of configuration inconsistencies, automatically triggering alarms or initiating a reconfiguration process to ensure that configuration deviations do not affect service quality. This verification mechanism achieves closed-loop verification of network configuration, making the entire network slicing configuration process controllable, traceable, and highly reliable, effectively improving the stability of the SDN network and the continuity of service operation. Attached Figure Description

[0018] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0019] Figure 1 is a flowchart illustrating the method described in Embodiment 1 of the present invention.

[0020] Figure 2 is a framework diagram of the system described in Embodiment 2 of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The concepts involved in this application will first be described with reference to the accompanying drawings. It should be noted that the following descriptions of various concepts are only for the purpose of making the content of this application easier to understand and do not constitute a limitation on the scope of protection of this application; furthermore, the embodiments and features in the embodiments of this application can be combined with each other unless otherwise specified. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] As shown in Figure 1, this invention provides a configuration method for a software-defined network, including the following steps: S1: Receiving user service requests and extracting service characteristics and quality of service requirements from the service requests, specifically: S11: Receiving user service requests, parsing the user service requests, and generating structured service request data containing fields such as service type, source and destination addresses, bandwidth parameters, latency parameters, and service priority. This includes receiving user service requests through a service request access module deployed on the user's ingress side. The service request is submitted in the form of a text description, the text content of which includes the service type that the user needs to activate, the source and destination addresses used for service communication, the expected bandwidth parameters, the acceptable latency parameters, and the service priority.

[0024] The business request access module passes the user's business request in text form to the natural language processing module.

[0025] The natural language processing module performs syntactic analysis and field location operations on the text content according to the predefined business request template. First, it identifies expressions related to the business type and maps them to the business type field in the business request template. Then, it parses the source address and destination address expressions in sequence and fills the parsing results into the source address field and destination address field in the business request template. Next, it parses the bandwidth parameter expressions and converts them into a standardized numerical representation of the bandwidth parameter field. Then, it parses the latency parameter expressions and converts them into a latency parameter field. Finally, it identifies the text content representing the business priority and fills it into the business priority field.

[0026] The natural language processing module combines all the above fields into structured business request data and outputs it to the next processing step.

[0027] S12: Identify business characteristics and service quality requirements from structured business request data, including: calling the feature extraction engine to perform feature recognition operations on the structured business request data generated in S11.

[0028] Based on a pre-built business feature rule base, the feature extraction engine first reads the business type field and business priority field from the business request data and encapsulates them into business features; then it reads the bandwidth parameter field and latency parameter field from the structured business request data and encapsulates them into service quality requirements.

[0029] The feature extraction engine strictly follows the field matching rules of the business feature rule base during the recognition process, without speculating or expanding the data content, ensuring that the extraction of business features and service quality requirements is deterministic.

[0030] A business feature rule base is a set of pre-defined rules that guides the system to accurately identify business types and priorities when parsing structured business request data, and to classify, map, and label them according to the rules.

[0031] The core functions of the business feature rule base include: field matching rules: defining the correspondence between each field in the structured business request data and the business feature, such as how the business type field should be identified and how the business priority field should be labeled.

[0032] Business type classification rules: Establish classification labels for possible business types so that the system can map the business type to a specific business category when identifying it. For example, "video conferencing business" belongs to the "real-time streaming media business category".

[0033] Service level determination rules: Based on business type and business priority, business characteristics are further mapped to deterministic service level labels, which are used as the basis for subsequent network slicing and service quality requirement quantification.

[0034] Data integrity rules: These rules specify the fields that must be included when identifying business features. For example, both a business type field and a business priority field must be present for a business feature to be considered successfully identified.

[0035] The business feature rule library is stored in the system in advance, and the feature extraction engine accurately identifies business request data based on the rules in the library.

[0036] The business feature rule base contains multiple business feature rules. Each rule consists of "business type field content," "business priority range," "corresponding business category," and "corresponding service level label." Examples are as follows: Rule 1: Video conferencing business rule; Business type field content: identified as "video conferencing"; Business priority range: priority value 1; Corresponding business category: "real-time interactive business"; Corresponding service level label: "high-level service"; Rule 2: File download business rule; Business type field content: identified as "file download"; Business priority range: priority value 3; Corresponding business category: "non-real-time data business"; Corresponding service level label: "medium-level service"; S13: Based on the preset mapping relationship between business types and feature rules, classify business features and generate business type identifiers with deterministic service level labels, including: reading the business type and business priority from the business features output by S12 through the business type classification module.

[0037] The business type classification module matches business types based on the preset mapping relationship between business types and feature rules, and assigns corresponding service level tags to the business types according to the mapping rules.

[0038] The business type classification module also combines the business priority field to accurately correct the service level label, so that each business type ultimately corresponds to a business type identifier with a deterministic service level label.

[0039] The business type identifier includes a business type field and a service level label field. This business type identifier is then output to the next processing step.

[0040] Example of the mapping relationship between preset business types and feature rules S14: Based on the business type identifier and service quality requirements, quantify the specific values ​​of bandwidth parameters and latency parameters, and generate a standardized set of service quality requirements indicators, including: calling the service quality requirements quantification module to perform standardized quantification processing on the bandwidth parameters and latency parameters extracted in S12.

[0041] Regarding bandwidth parameters, the Quality of Service (QoS) requirement quantification module converts all bandwidth parameters into Mbps units and imposes boundary restrictions on bandwidth values ​​that exceed the specified range, thereby generating specific bandwidth values ​​with unified units of measurement.

[0042] The Service Quality Requirements Quantification module performs the following processing flow for bandwidth parameters: 1. Bandwidth parameter parsing: Receives the bandwidth parameter field from the Service Quality Requirements output by S12. The bandwidth parameter field contains a numerical part and a unit identifier part.

[0043] The Service Quality Demand Quantification module first splits the bandwidth parameter field into two parts: bandwidth value and bandwidth unit. The bandwidth unit is limited to one of three predefined units: Kbps, Mbps, and Gbps.

[0044] 2. Unified conversion to Mbps unit: The service quality demand quantification module pre-stores a unit conversion table: the unit conversion factor for Kbps is 1 / 1000; the unit conversion factor for Mbps is 1; and the unit conversion factor for Gbps is 1000.

[0045] Find the corresponding unit conversion factor in the unit conversion table based on the bandwidth unit, multiply the bandwidth value by the unit conversion factor, and obtain the specific bandwidth value measured in Mbps.

[0046] The calculation result retains a fixed decimal precision, such as retaining one decimal place or directly rounding to the nearest integer, to form the final specific value of the bandwidth.

[0047] 3. Boundary limits for bandwidth values: The service quality requirement quantification module pre-configures the range of bandwidth parameters, including the minimum bandwidth threshold and the maximum bandwidth threshold, both of which are measured in Mbps.

[0048] When the converted bandwidth value is less than the minimum bandwidth threshold, adjust the bandwidth value to the minimum bandwidth threshold; when the converted bandwidth value is greater than the maximum bandwidth threshold, adjust the bandwidth value to the maximum bandwidth threshold; when the converted bandwidth value is between the minimum bandwidth threshold and the maximum bandwidth threshold, keep the original value unchanged.

[0049] After the above boundary restriction processing, the service quality requirement quantification module outputs a specific bandwidth value with a unified unit of measurement and within the specified range.

[0050] For latency parameters, the service quality requirement quantification module converts them into specific latency values ​​accurate to the millisecond level and sets an upper limit for acceptable latency based on the service level label.

[0051] The service quality requirement quantification module performs the following processing flow for latency parameters: 1. Latency parameter parsing and millisecond-level conversion: Receives the latency parameter field from the service quality requirement output by S12. The latency parameter field contains a numerical part and a unit identifier part. The latency unit is limited to one of two predefined units: ms and s.

[0052] The Service Quality Requirements Quantification module splits the latency parameter field into two parts: latency value and latency unit.

[0053] When the latency unit is seconds (s), the service quality requirement quantification module converts the latency value into a specific latency value measured in milliseconds by multiplying the latency value by one thousand. When the latency unit is milliseconds (ms), the service quality requirement quantification module directly uses the latency value as the specific latency value measured in milliseconds.

[0054] The converted latency value is rounded or rounded down to the nearest millisecond.

[0055] 2. Set the upper limit of acceptable latency based on the service level label: The service quality demand quantification module pre-stores a mapping table between the service level label and the upper limit of acceptable latency. For example: when the service level label is "High-level service", the corresponding upper limit of acceptable latency is 50ms; when the service level label is "Medium-level service", the corresponding upper limit of acceptable latency is 150ms; when the service level label is "Low-level service", the corresponding upper limit of acceptable latency is 300ms.

[0056] The service quality requirement quantification module reads the service level label output by S13 and finds the upper limit of the acceptable latency corresponding to the service level label in the mapping table.

[0057] When the specific delay value is less than or equal to the upper limit of acceptable delay, the specific delay value is directly used as the standardized specific delay value; when the specific delay value is greater than the upper limit of acceptable delay, the specific delay value is truncated to the upper limit of acceptable delay, and the upper limit is used as the standardized specific delay value.

[0058] Finally, the service quality requirement quantification module combines the specific bandwidth values ​​with the specific latency values ​​to form a standardized set of service quality requirement indicators, which are then used as input data for S2.

[0059] S2: Based on business characteristics, quality of service requirements, and real-time collected network topology status information, generate a network slicing strategy with a specific resource guarantee level. Specifically: S21: Based on business characteristics and quality of service requirements, determine a specific resource guarantee level by querying the preset service level agreement mapping rules, and generate a key resource requirement description that includes bandwidth reservation value, latency upper limit value, and isolation type. This includes: first receiving the business characteristics output by S12 and the standardized set of quality of service requirement indicators output by S14.

[0060] Access the policy database through the service level agreement query module. The policy database contains preset service level agreement mapping rules. Each mapping rule consists of a service type field, a service priority field, a corresponding specific resource guarantee level, a bandwidth reservation value, a latency limit value, and an isolation type.

[0061] The following are examples of preset business level agreement mapping rules: Example rule 1: Video conferencing service mapping rule; Service type field: video conferencing; Service priority field: 1; Specific resource guarantee level: high guarantee level; Bandwidth reservation value: 20Mbps; Latency limit value: 50ms; Isolation type: strong isolation; Example rule 2: Voice call service mapping rule; Service type field: voice call; Service priority field: 1; Specific resource guarantee level: high guarantee level; Bandwidth reservation value: 5Mbps; Latency limit value: 30ms; Isolation type: strong isolation; When the business level agreement query module receives the service feature: if the service type = "video conferencing" and the service priority = 1; match example rule 1; get high guarantee level + 20Mbps + 50ms + strong isolation; The business level agreement query module performs a complete match query operation in the policy database based on the service type and service priority in the service feature. The query operation includes: (1) using the service type field as the first matching condition; (2) using the service priority field as the second matching condition; (3) retrieving a unique mapping rule in the policy database that satisfies both matching conditions.

[0062] Once a matching mapping rule is found, the service level agreement query module reads the corresponding specific resource protection level, bandwidth reservation value, latency limit value, and isolation type from the mapping rule.

[0063] Subsequently, the service level agreement query module encapsulates the bandwidth reservation value, latency limit value, and isolation type to form a description of key resource requirements.

[0064] The description of key resource requirements is organized in the form of structured data, including explicit bandwidth reservation value field, latency limit value field, and isolation type field, for use in step S22.

[0065] S22: Combining the key resource requirement description and network topology status information, the path calculation engine executes the constrained shortest path first algorithm to calculate one or more candidate paths that meet the key resource requirement description, and generates a path resource allocation scheme including path identifiers, bandwidth allocation details, and link latency metrics. This includes: first, receiving the key resource requirement description output from S21 and the real-time collected network topology status information. The network topology status information includes the link bandwidth occupancy, available remaining bandwidth, link latency metrics, and link connection relationships for all links.

[0066] Before calculating candidate paths, the path calculation engine sets constraints based on the description of key resource requirements: (1) bandwidth reservation value as bandwidth constraint; (2) latency upper limit value as latency constraint.

[0067] The path calculation engine executes the constrained shortest path first (SLT) algorithm on the network topology graph. During algorithm execution, the path calculation engine operates according to the following steps: First, it filters all links in the topology, retaining only links whose available remaining bandwidth is greater than or equal to the bandwidth reservation value; second, it assigns a corresponding link latency metric to each link in the filtered link set; third, it performs path search using the link latency metric as the path cost, calculating all paths that meet the upper limit of latency constraints; fourth, it sorts the paths that meet the above conditions in ascending order of total path latency, generating one or more candidate paths.

[0068] The path calculation engine further generates a path resource allocation scheme for each candidate path. The path resource allocation scheme includes a path identifier field, a bandwidth allocation details field, and a link latency metric field. The bandwidth allocation details field records the actual allocable bandwidth available for each link; the link latency metric field records the link latency metric for each link in the path and the total path latency. The system outputs the complete path resource allocation scheme to S23.

[0069] S23: Integrate specific resource protection levels, key resource requirement descriptions, and path resource allocation schemes to construct a complete network slicing strategy that includes unique slice identifiers, resource reservation parameters, and path binding relationships. This includes: first, receiving the specific resource protection level and key resource requirement descriptions output from S21, and receiving the path resource allocation scheme output from S22. Then, calling the network slicing strategy construction module to generate the complete network slicing strategy.

[0070] The network slicing strategy construction module performs the following operations: (1) Create a unique slice identifier for each slice generation process. The unique slice identifier is generated by combining the system timestamp and the random number sequence; (2) Directly write the bandwidth reservation value and the latency limit value in the description of key resource requirements into the resource reservation parameter field; (3) Read the path identifier from the path resource allocation scheme and fill the path identifier into the path binding relationship field. At the same time, record the bandwidth allocation details and link latency indicators in the path resource allocation scheme to form a complete path binding relationship description.

[0071] The final generated complete network slicing policy includes: a unique slice identifier, resource reservation parameters, path binding relationships, and a specific resource protection level. The network slicing policy construction module provides this complete network slicing policy to step S3 to generate device-independent general configuration instructions.

[0072] S3: Based on the network slicing policy and pre-stored device capability information, generate device-independent general configuration instructions. These instructions include a set of parameters to ensure quality of service requirements. Specifically: S31: Parse the network slicing policy, extracting the unique slice identifier, resource reservation parameters, and path binding relationships, and transforming them into a set of device-independent slice configuration elements. This includes calling the policy parsing engine to perform parsing operations on the network slicing policy output in S23. The policy parsing engine parses the field structure of the network slicing policy level by level according to predefined policy syntax rules. The parsing process includes the following operations: 1. Parse the unique slice identifier: The policy parsing engine reads the unique slice identifier field in the network slicing policy, determines the value of this field through syntax rules, and records this value as the basic element of the slice identifier.

[0073] 2. Parsing Resource Reservation Parameters: The policy parsing engine reads the resource reservation parameter field from the network slicing policy, and sequentially parses the bandwidth reservation value and latency limit value in this field, using them as slice resource configuration elements. The policy parsing engine also verifies the format and numerical range of the bandwidth reservation value and latency limit value to ensure they meet the predefined resource configuration requirements.

[0074] Parsing Path Binding Relationships: The policy parsing engine reads the path binding relationship fields, extracts the path identifier, bandwidth allocation details of each link in the path, and link latency indicators. After parsing, the policy parsing engine structures the path binding relationship for subsequent construction of device-independent instruction content.

[0075] After parsing, the policy parsing engine transforms the unique slice identifier, resource reservation parameters, and path binding relationships into a set of slice configuration elements independent of specific devices. Each slice configuration element is organized in the form of field name, field type, and field value, forming a structured data set, which serves as the input for step S32.

[0076] S32: Query device capability information. Based on the device manufacturer, model, and supported protocols recorded in the device capability information, convert the slice configuration elements into a set of intermediate instructions conforming to the standard data model specification. This includes: reading pre-stored device capability information through the model-driven abstraction module. The device capability information contains multiple fields, indicating the device manufacturer, device model, and the standard protocol types supported by the device. The model-driven abstraction module first determines the data model specification to be used based on the standard protocol types recorded in the device capability information, such as the standard data model specification based on the unified YANG model.

[0077] After determining to use the YANG model, the model-driven abstraction module maps the slice configuration elements output by S31 to intermediate instruction sets item by item according to the YANG model structure definition. The mapping process includes: 1. Slice identifier mapping: mapping the unique slice identifier to the slice identifier node defined in the YANG model.

[0078] 2. Resource reservation parameter mapping: Map the bandwidth reservation value in the slice configuration element to the bandwidth reservation node corresponding to the YANG model, and map the latency upper limit value to the latency upper limit node corresponding to the YANG model.

[0079] 3. Path binding relationship mapping: Map the path identifier to the path node, map the link bandwidth allocation details to the link bandwidth node, and map the link latency metric to the link latency node.

[0080] After the above mapping is executed, the model-driven abstraction module combines all the mapping nodes to generate a complete set of intermediate instructions.

[0081] The intermediate instruction set is organized in a tree structure that conforms to the standard data model specification, and can be adapted to the unified parsing mechanism of different manufacturers' devices.

[0082] S33: Integrate the intermediate instruction set and inject the parameter set used to ensure service quality requirements. Encapsulate and generate a device-independent universal configuration instruction that can be uniformly recognized by devices from different manufacturers. This includes: calling the instruction encapsulation module and using the intermediate instruction set output in step S32 as the basic instruction content. Subsequently, read the parameter set used to ensure service quality requirements from the standardized service quality requirement indicator set output in step S14, and integrate this parameter set with the intermediate instruction set. The integration process includes: filling the specific bandwidth and latency parameters into the corresponding YANG parameter nodes in the intermediate instruction set.

[0083] After integration, the instruction encapsulation module serializes the intermediate instruction set and parameter set into a JSON or XML data file. The serialization process follows structured data rules, generating a unique key-value structure for each instruction field.

[0084] The resulting device-independent universal configuration instructions are output in the form of JSON or XML data files and can be uniformly recognized and executed by network devices from different manufacturers.

[0085] S4: Dynamically compile general configuration instructions into device-specific instructions corresponding to the target network device type, and send them to the target network device for execution through the SDN controller so that the target network device can run according to the quality of service requirements. Specifically: S41: Select the corresponding protocol adapter from the protocol adapter library according to the device type of the target network device, and load the instruction compilation template that matches the device type. In S41, first read the device type information of the target network device from the pre-stored device capability information. The device type information includes the device manufacturer identifier field and the device model identifier field.

[0086] The protocol adapter management module is then invoked to access the protocol adapter library. The protocol adapter library stores multiple protocol adapters, each indexed by the device manufacturer's identifier and the device model identifier, and encapsulates the protocol stack and data format definitions required by the corresponding device.

[0087] The protocol adapter management module performs an index query based on the target network device's manufacturer and model identifiers, and loads the matched protocol adapters into the runtime environment. The module further retrieves the corresponding instruction compilation template from the instruction compilation template library based on the device type. The instruction compilation template is organized using a field mapping structure, recording the device-specific instruction format, device instruction field names, and the order in which the device fields are filled.

[0088] Finally, the loaded protocol adapter is bound to the instruction compilation template, providing a basis for parsing and compilation for the instruction conversion process in step S42.

[0089] S42: Use the protocol adapter to parse the general configuration instructions and convert them into device-specific instructions that the target network device can recognize and execute according to the instruction compilation template. This includes: first, inputting the device-independent general configuration instructions output by S33 into the instruction parsing module of the protocol adapter.

[0090] The protocol adapter's embedded syntax parser parses the general configuration instructions according to the structural order of the standard data model, breaking down the slice identifier field, resource reservation parameter field, and path binding relationship field into a set of processable configuration items.

[0091] The protocol adapter then starts its internal rules engine. Based on the field mapping rules defined in the instruction compilation template, the rules engine maps each parsed configuration item to a device-specific instruction field of the target network device. For example, it maps the bandwidth parameter field in the general configuration instruction to the port bandwidth configuration field in the device instruction, and the latency parameter field to the forwarding latency parameter field in the device instruction.

[0092] The instruction compilation template specifies the order in which device instruction fields are filled. The protocol adapter fills in each configuration item into the device instruction fields in the order specified, ensuring that the generated device-specific instructions meet the syntax, field structure, and protocol stack requirements of the target network device.

[0093] Finally, the protocol adapter compiles all fields to generate a complete set of device-specific instructions, which is then provided to step S43 for execution.

[0094] S43: The SDN controller sends device-specific commands to the target network device via its southbound interface and receives configuration confirmation information from the target network device to confirm that the target network device is operating according to the quality of service requirements. This includes: the SDN controller calling its southbound interface module to package the device-specific commands generated in S42 into a message structure recognizable by the southbound interface. The southbound interface module encodes the message according to the southbound interface protocol supported by the target network device and sends it to the target network device through the control channel.

[0095] Once the target network device successfully receives the device-specific command, it executes its internal command parsing program to update the device's operational configuration according to the port configuration field, path parameter field, and resource reservation field in the device-specific command. After executing the configuration, the device generates a configuration confirmation message and returns it to the SDN controller via the southbound interface.

[0096] Upon receiving the configuration confirmation information, the SDN controller executes a configuration verification step. During this step, the device operating parameter fields from the configuration confirmation information are read and compared field-by-field with the parameter set included in the general configuration instructions used to ensure quality of service requirements.

[0097] When the comparison results are consistent, it confirms that the target network device is operating normally according to the quality of service requirements; when the comparison results are inconsistent, the alarm module is triggered to issue an alarm message, or the reconfiguration process is started to reissue the device-specific instructions.

[0098] Example 2, as shown in Figure 2, is a configuration system for a software-defined network (SDN) to implement the aforementioned SDN configuration method. It includes the following modules: a service request access module for receiving user service requests and submitting them to a natural language processing module for further parsing; a natural language processing module for parsing the user service requests provided by the service request access module, generating structured service request data containing fields such as service type, source and destination addresses, bandwidth parameters, latency parameters, and service priority, and providing the structured service request data to the subsequent service feature analysis unit; and a service type classification module for classifying the structured service request data. The system classifies business characteristics according to the preset mapping relationship between business type and feature rules, using the business type and business priority fields, and generates business type identifiers with deterministic service level labels. The service quality requirement quantification module is used to standardize the bandwidth parameters and generate specific bandwidth values ​​based on the business type identifier and the bandwidth and latency parameters in the structured business request data, and to impose millisecond-level precision constraints on the latency parameters and generate specific latency values, thus forming a standardized set of service quality requirement indicators. The business level agreement query module is used to query preset values ​​stored in the strategy database based on business characteristics and the standardized set of service quality requirement indicators. The service level agreement mapping rules determine specific resource guarantee levels and generate key resource requirement descriptions including bandwidth reservation values, latency limits, and isolation types. The network slicing strategy construction module combines the key resource requirement descriptions with path resource allocation schemes generated based on real-time collected network topology status information. It integrates specific resource guarantee levels, key resource requirement descriptions, and path resource allocation schemes to construct a network slicing strategy containing unique slice identifiers, resource reservation parameters, and path binding relationships. The model-driven abstraction module extracts the unique slice identifier and resource reservation parameters from the network slicing strategy based on the device manufacturer, model, and supported protocols recorded in pre-stored device capability information. The parameter and path binding relationship is transformed into a slice configuration element that is independent of specific devices, and the slice configuration element is mapped to an intermediate instruction set according to the standard data model specification; the instruction encapsulation module is used to inject a parameter set to ensure service quality requirements on the intermediate instruction set generated by the model-driven abstraction module, encapsulate the intermediate instruction set, and generate device-independent general configuration instructions; the protocol adapter management module is used to select the protocol adapter corresponding to the device manufacturer and model from the protocol adapter library according to the device type of the target network device, load the instruction compilation template matching the target network device type, and provide the protocol adapter and instruction compilation template to the instruction parsing module;The instruction parsing module calls the protocol adapter to parse the syntax of the general configuration instructions generated by the instruction encapsulation module. Based on the instruction compilation template, it maps and populates each configuration item in the general configuration instructions (based on the standard data model) into device-specific instructions that the target network device can recognize and execute. The southbound interface module sends the device-specific instructions generated by the instruction parsing module to the target network device through the southbound interface of the SDN controller and receives configuration confirmation information returned by the target network device. The alarm module, upon receiving the configuration confirmation information, compares the device operating parameters fed back in the confirmation information with the set of parameters included in the general configuration instructions to ensure quality of service requirements. If the comparison results are inconsistent, it generates alarm information or triggers a reconfiguration process, thereby ensuring that the target network device operates according to quality of service requirements.

[0099] The embodiments and / or implementation methods described above are merely preferred embodiments and / or implementation methods for implementing the technology of the present invention, and are not intended to limit the implementation methods of the present invention in any way. Any person skilled in the art can make some modifications or alterations to other equivalent embodiments without departing from the scope of the technical means disclosed in the present invention, but these should still be considered as technologies or embodiments substantially the same as the present invention. Specific examples have been used in this document to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. The above descriptions are merely preferred embodiments of this application. It should be noted that due to the limitations of textual expression, and the objective existence of infinite specific structures, for those skilled in the art, several improvements, modifications, or changes can be made without departing from the principles of this application, and the above technical features can also be combined in an appropriate manner; these improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other occasions without modification, should all be considered within the scope of protection of this application.

Claims

1. A configuration method for a software-defined network, characterized in that, The process includes the following steps: receiving user service requests and extracting service characteristics and quality of service (QoS) requirements from the service requests; generating a network slicing policy with resource guarantee levels based on the service characteristics, the QoS requirements, and real-time collected network topology status information; generating device-independent general configuration instructions based on the network slicing policy and pre-stored device capability information, wherein the general configuration instructions include a set of parameters for guaranteeing the QoS requirements; dynamically compiling the general configuration instructions into device-specific instructions corresponding to the target network device type, and issuing them to the target network device for execution through the SDN controller, so that the target network device operates according to the QoS requirements.

2. The configuration method for a software-defined network according to claim 1, characterized in that, The step of receiving user service requests and extracting service features and service quality requirements from the service requests includes: receiving user service requests, parsing the user service requests, and generating structured service request data containing fields such as service type, source and destination addresses, bandwidth parameters, latency parameters, and service priority; identifying service features and service quality requirements from the structured service request data, wherein the service features include service type and service priority, and the service quality requirements include bandwidth parameters and latency parameters; classifying the service features based on a preset mapping relationship between service types and feature rules, and generating service type identifiers with deterministic service level labels; and quantifying the specific values ​​of the bandwidth parameters and latency parameters according to the service type identifiers and the service quality requirements, and generating a standardized set of service quality requirement indicators.

3. The configuration method for a software-defined network according to claim 2, characterized in that, The parsing of the user business request is accomplished by the natural language processing module. The natural language processing module extracts key information from the text-based user business request and fills it into a predefined business request template to generate the structured business request data.

4. The configuration method for a software-defined network according to claim 3, characterized in that, The identification of business characteristics and service quality requirements is achieved through a feature extraction engine. The feature extraction engine reads and encapsulates the business characteristics and service quality requirements from the corresponding fields of the structured business request data based on a pre-set business characteristic rule library.

5. The configuration method for a software-defined network according to claim 4, characterized in that, The generation of a network slicing strategy with a specific resource guarantee level includes: based on the service characteristics and the quality of service requirements, determining the specific resource guarantee level by querying a preset service level agreement mapping rule, and generating a key resource requirement description including bandwidth reservation value, latency upper limit value, and isolation type; combining the key resource requirement description with the network topology status information, using a path calculation engine to execute a constrained shortest path first algorithm to calculate one or more candidate paths that conform to the key resource requirement description, and generating a path resource allocation scheme including path identifier, bandwidth allocation details, and link latency indicators; integrating the specific resource guarantee level, the key resource requirement description, and the path resource allocation scheme to construct a complete network slicing strategy including a unique slice identifier, resource reservation parameters, and path binding relationships.

6. The configuration method for a software-defined network according to claim 5, characterized in that, The preset service level agreement mapping rules are stored in the policy database, which associates different service types with corresponding specific resource guarantee levels, bandwidth reservation values, latency limits, and isolation types.

7. The configuration method for a software-defined network according to claim 6, characterized in that, The generation of device-independent general configuration instructions includes: parsing the network slicing policy, extracting the unique slice identifier, resource reservation parameters, and path binding relationships, and converting them into a set of slice configuration elements independent of specific devices; querying the device capability information, and converting the slice configuration elements into an intermediate instruction set conforming to the standard data model specification based on the device manufacturer, model, and supported protocols recorded in the device capability information; integrating the intermediate instruction set, injecting the parameter set used to ensure the quality of service requirements, and encapsulating it to generate a final device-independent general configuration instruction that can be uniformly identified by devices from different manufacturers.

8. The configuration method for a software-defined network according to claim 7, characterized in that, The network slicing policy is implemented through a policy parsing engine. The policy parsing engine extracts the unique slice identifier, resource reservation parameters, and path binding relationships from the network slicing policy according to predefined policy syntax rules, and outputs them as structured slice configuration elements.

9. A configuration method for a software-defined network according to claim 8, characterized in that, The general configuration instructions are dynamically compiled into device-specific instructions corresponding to the target network device type, and then sent to the target network device for execution via the SDN controller. This includes: selecting a corresponding protocol adapter from the protocol adapter library based on the device type of the target network device, and loading an instruction compilation template that matches the device type; parsing the general configuration instructions using the protocol adapter, and converting the general configuration instructions into device-specific instructions that the target network device can recognize and execute according to the instruction compilation template; sending the device-specific instructions to the target network device through the southbound interface of the SDN controller, and receiving configuration confirmation information returned by the target network device to confirm that the target network device is operating according to the quality of service requirements.

10. A configuration system for a software-defined network, used to implement the configuration method for a software-defined network as described in any one of claims 1-9, characterized in that, It includes the following modules: Business Request Access Module: used to receive user business requests and submit them to the Natural Language Processing Module for subsequent parsing and processing; Natural Language Processing Module: used to parse the user business requests provided by the Business Request Access Module, generate structured business request data containing fields such as business type, source and destination addresses, bandwidth parameters, latency parameters, and business priority, and provide the structured business request data to the subsequent business feature analysis unit. The business type classification module classifies business characteristics based on the business type and business priority fields in structured business request data, according to a preset mapping relationship between business type and feature rules, and generates business type identifiers with deterministic service level labels. The service quality requirement quantification module standardizes the bandwidth parameters and generates specific bandwidth values, and imposes millisecond-level precision constraints on the latency parameters and generates specific latency values, based on the business type identifiers and the bandwidth and latency parameters in structured business request data, thus forming a standardized set of service quality requirement indicators. The business level agreement query module queries preset business level agreement mapping rules stored in the policy database based on business characteristics and the standardized set of service quality requirement indicators, determines specific resource guarantee levels, and generates key resource requirement descriptions including bandwidth reservation values, latency limits, and isolation types. The network slicing strategy construction module combines key resource requirement descriptions with path resource allocation schemes generated based on real-time collected network topology status information. It integrates specific resource protection levels, key resource requirement descriptions, and path resource allocation schemes to construct a network slicing strategy containing unique slice identifiers, resource reservation parameters, and path binding relationships. The model-driven abstraction module, based on pre-stored device capability information (including device manufacturer, model, and supported protocols), transforms the unique slice identifiers, resource reservation parameters, and path binding relationships extracted from the network slicing strategy into device-independent slice configuration elements. It then maps these slice configuration elements to intermediate instruction sets according to standard data model specifications. The instruction encapsulation module, based on the intermediate instruction set generated by the model-driven abstraction module, injects a parameter set to ensure quality of service requirements, encapsulates the intermediate instruction set, and generates device-independent general configuration instructions. The protocol adapter management module is used to select a protocol adapter from the protocol adapter library that corresponds to the device manufacturer and model based on the device type of the target network device, load an instruction compilation template that matches the target network device type, and provide the protocol adapter and instruction compilation template to the instruction parsing module. The instruction parsing module calls the protocol adapter, performs syntax parsing on the general configuration instructions generated by the instruction encapsulation module, and maps and fills the configuration items based on the standard data model in the general configuration instructions into device-specific instructions that the target network device can recognize and execute, according to the instruction compilation template. The southbound interface module sends the device-specific instructions generated by the instruction parsing module to the target network device through the southbound interface of the SDN controller and receives the configuration confirmation information returned by the target network device. The alarm module, upon receiving the configuration confirmation information, compares the device operating parameters fed back in the configuration confirmation information with the parameter set for ensuring quality of service requirements contained in the general configuration instructions. When the comparison results are inconsistent, it generates alarm information or triggers a reconfiguration process, thereby ensuring that the target network device operates according to the quality of service requirements.

Images