SDN model mapping method, device, equipment and storage medium

Abstract

The present application provides a model mapping method, apparatus, device and storage medium for SDN, which responds to the service request reported by the service device to obtain each target service callback point, generates the service instance corresponding to each target service callback point, generates each expected service model according to each service instance and the current service model of each service instance, triggers the service callback function of each target service callback point to generate each expected configuration model according to each expected service model, compares each expected configuration model with each current configuration model to obtain each difference configuration model and sends it to the southbound device, so that the southbound device implements the configuration model change according to each difference configuration model. Only a small amount of secondary development code is required, such as defining service callback points and writing service callback functions, to realize the automatic deduction and mapping of the north-south interface, automatically realize the full range of service scenarios, thereby quickly responding to service needs and facilitating the rapid deployment and implementation of new services.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a SDN model mapping method, apparatus, device, and storage medium. Background Art

[0002] The standard architecture of the Software Defined Network (SDN) system, defined by the Open Networking Foundation (ONF), an international organization for standardization, is primarily divided into the application layer, the controller layer, and the infrastructure layer. From the perspective of the controller layer, the interface with the application layer is defined as the northbound interface (NBI), and the interface with the infrastructure layer is defined as the southbound interface (SBI). By encapsulating the northbound interface, the application layer can access various network resources, control the resource status of the entire network, and centrally schedule resources through software programming.

[0003] For SDN controllers, mainstream open-source controllers (such as OpenDayLight) are primarily model-driven, using the YANG model to uniformly define north-south interface models. Northbound interfaces primarily use the YANG-driven RestConf protocol, while southbound interfaces use the YANG-driven NetConf or RestConf protocols. When developing services based on open-source SDN controllers, the primary development effort involves defining the northbound service YANG model, introducing the southbound device YANG model, and writing the north-south model mapping logic for each RestConf interface.

[0004] However, this existing development effort has many shortcomings. For example, RestConf interfaces are numerous, and according to its specifications, each YANG node must support operations such as add, delete, query, and modify via HTTP (HyperText Transfer Protocol). Since a typical business model typically has dozens, or even hundreds, of nodes, this leads to a significant amount of secondary development work. Furthermore, manually maintaining the relationships between north-south YANG models through hardcoding is inefficient and prone to errors. These factors slow SDN controllers to respond to business needs and prevent them from rapidly deploying and implementing new services. Furthermore, due to these shortcomings, during actual project implementation, SDN controllers typically only customize certain business scenarios based on application layer requirements, implementing only a subset of the interfaces in the RestConf specification and failing to implement all business scenarios. Summary of the Invention

[0005] The present application provides an SDN model mapping method, apparatus, device and storage medium, which are used to solve the technical problems that existing model mapping solutions only implement some interfaces in the RestConf specification and are not convenient for implementing full business scenarios, and will cause the business response speed to slow down and fail to utilize the rapid deployment and implementation of new businesses.

[0006] In a first aspect, the present application provides an SDN model mapping method, comprising:

[0007] Responding to a service request reported by a service device, obtaining each target service callback point, wherein each target service callback point is a starting point of a model mapping process, and the service device is deployed in the application layer of the SDN architecture;

[0008] Generate a service instance corresponding to each target service callback point, and generate each expected service model based on each service instance and the current service model of each service instance;

[0009] triggering a service callback function of each target service callback point to generate each expected configuration model according to each expected service model, and comparing each expected configuration model with each current configuration model to obtain each difference configuration model;

[0010] Each of the differential configuration models is issued to a southbound device, so that the southbound device implements a configuration model change according to each of the differential configuration models, and the southbound device is deployed at an infrastructure layer of the SDN architecture.

[0011] In one possible design, the step of obtaining each target service callback point in response to the service request reported by the service device includes:

[0012] Customize multiple service callback points, where the granularity of the service callback points is positively correlated with the Yang model hierarchy of the SDN architecture;

[0013] Receiving the service request reported by the service device through the RestConf interface;

[0014] Each service callback point associated with the service request is acquired from the multiple service callback points according to the service request, and each associated service callback point is determined as each target service callback point.

[0015] In one possible design, obtaining each service callback point associated with the service request from the multiple service callback points according to the service request includes:

[0016] Searching for each service callback point associated with the current service request from the multiple service callback points according to the service path carried by the service request and using a traversal algorithm;

[0017] The traversal algorithm includes a downlink traversal algorithm and an uplink traversal algorithm.

[0018] In one possible design, generating each expected business model according to each business instance and the current business model of each business instance includes:

[0019] According to the path of each service instance, query the current configuration model of each service instance from a preset database;

[0020] Each business instance is merged with the queried current business model of each business instance to obtain each expected business model.

[0021] In a possible design, merging each business instance with the queried current business model of each business instance includes:

[0022] Merging each business instance with the queried current business model of each business instance according to a model merging algorithm;

[0023] The model merging algorithm includes at least one of a merging algorithm corresponding to a creation request, a merging algorithm corresponding to an incremental modification request, a merging algorithm corresponding to a full modification request, and a merging algorithm corresponding to a deletion request.

[0024] In a possible design, before comparing each expected configuration model with each current configuration model to obtain each difference configuration model, the method further includes:

[0025] For the current business model of each business instance, the business callback function of each corresponding target business callback point is triggered to generate each current configuration model.

[0026] In one possible design, comparing each expected configuration model with each current configuration model to obtain each difference configuration model includes:

[0027] Each of the expected configuration models is compared with each of the current configuration models one by one to obtain each of the difference configuration models.

[0028] In one possible design, the service model implemented by the Yang model includes an l3vpn-svc model.

[0029] In a second aspect, the present application provides an SDN model mapping device, comprising:

[0030] An acquisition module is configured to acquire each target service callback point in response to a service request reported by a service device, wherein each target service callback point is a starting point of a model mapping process, and the service device is deployed in the application layer of the SDN architecture;

[0031] A first processing module is configured to generate a service instance corresponding to each target service callback point, and generate each expected service model according to each service instance and the current service model of each service instance;

[0032] A second processing module is configured to trigger a service callback function of each target service callback point to generate each expected configuration model according to each expected service model, and compare each expected configuration model with each current configuration model to obtain each difference configuration model;

[0033] The sending module is used to send each difference configuration model to the southbound device, so that the southbound device implements the configuration model change according to each difference configuration model. The southbound device is deployed in the infrastructure layer of the SDN architecture.

[0034] In one possible design, the acquisition module is used to:

[0035] Customize multiple service callback points, where the granularity of the service callback points is positively correlated with the Yang model hierarchy of the SDN architecture;

[0036] Receiving the service request reported by the service device through the RestConf interface;

[0037] Each service callback point associated with the service request is acquired from the multiple service callback points according to the service request, and each associated service callback point is determined as each target service callback point.

[0038] In one possible design, the acquisition module is further configured to:

[0039] Searching for each service callback point associated with the current service request from the multiple service callback points according to the service path carried by the service request and using a traversal algorithm;

[0040] The traversal algorithm includes a downlink traversal algorithm and an uplink traversal algorithm.

[0041] In one possible design, the first processing module is configured to:

[0042] According to the path of each business instance, query the current business model of each business instance from a preset database;

[0043] Each business instance is merged with the queried current business model of each business instance to obtain each expected business model.

[0044] In one possible design, the first processing module is further configured to:

[0045] Merging each business instance with the queried current business model of each business instance according to a model merging algorithm;

[0046] The model merging algorithm includes at least one of a merging algorithm corresponding to a creation request, a merging algorithm corresponding to an incremental modification request, a merging algorithm corresponding to a full modification request, and a merging algorithm corresponding to a deletion request.

[0047] In one possible design, the second processing module is configured to:

[0048] For the current business model of each business instance, the business callback function of each corresponding target business callback point is triggered to generate each current configuration model.

[0049] In one possible design, the second processing module is further configured to:

[0050] Each of the expected configuration models is compared with each of the current configuration models one by one to obtain each of the difference configuration models.

[0051] In one possible design, the service model implemented by the Yang model includes an l3vpn-svc model.

[0052] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0053] The memory stores computer-executable instructions;

[0054] The processor executes the computer-executable instructions stored in the memory to implement any possible SDN model mapping method provided in the first aspect.

[0055] In a fourth aspect, the present application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any possible SDN model mapping method provided in the first aspect.

[0056] In a fifth aspect, the present application provides a computer program product, comprising computer-executable instructions, which, when executed by a processor, are used to implement any possible SDN model mapping method provided in the first aspect.

[0057] The present application provides a model mapping method, apparatus, device and storage medium of SDN. First, the service request reported by the service device is responded to to obtain each target service callback point. Each target service callback point is the starting point of the model mapping process. The service device is deployed in the application layer of the SDN architecture. Then, the service instance corresponding to each target service callback point is generated, and each expected service model is generated according to each service instance and the current service model of each service instance. Then, the service callback function of each target service callback point is triggered to generate each expected configuration model according to each expected service model. Each expected configuration model is compared with each current configuration model to obtain each difference configuration model. Each difference configuration model is sent to the southbound device so that the southbound device implements the configuration model change according to each difference configuration model. The southbound device is deployed in the infrastructure layer of the SDN architecture. Only a small amount of secondary development code is required, such as defining service callback points and writing service callback functions, to realize the automatic deduction and mapping of the north-south interface and automatically realize the full range of service scenarios, thereby quickly responding to service needs and facilitating the rapid deployment and implementation of new services. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0059] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application;

[0060] Figure 2 A flow chart of an SDN model mapping method provided in an embodiment of the present application;

[0061] Figure 3 A schematic diagram of a process for generating an expected business model is provided for an embodiment of the present application;

[0062] Figure 4 A schematic diagram of a north-south model mapping process provided in an embodiment of the present application;

[0063] Figure 5 A schematic diagram of the structure of an L3VPN-SVC model provided in an embodiment of the present application;

[0064] Figure 6 A schematic diagram of the structure of a southbound device Yang model provided in an embodiment of the present application;

[0065] Figure 7 A schematic diagram of the structure of an SDN model mapping device provided in an embodiment of the present application;

[0066] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0067] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of methods and apparatus consistent with certain aspects of the present application, as detailed in the appended claims.

[0068] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the numbers used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0069] For SDN controllers, currently mainstream open-source controllers (such as OpenDayLight) are primarily model-driven, using the YANG model to uniformly define north-south interface models. Northbound interfaces primarily use the YANG model-driven RestConf protocol, while southbound interfaces use the YANG model-driven NetConf or RestConf protocols. When developing services based on open-source SDN controllers, the primary development effort involves defining northbound service YANG models, importing southbound device YANG models, and writing north-south model mapping logic for each RestConf interface. However, this existing development approach has numerous drawbacks. For example, RestConf interfaces vary widely, and according to their specifications, each YANG node must support operations such as add, delete, query, and modify via HTTP (HyperText Transfer Protocol). This leads to a significant amount of development work, as a typical service model may contain dozens or even hundreds of nodes. Furthermore, manually maintaining the relationships between north-south YANG models through hard-coding is inefficient and error-prone. Due to these reasons, the SDN controller's response speed to services becomes slow and it cannot quickly deploy and implement new services. In addition, due to these defects, during the actual project implementation process, the general SDN controller will only customize some business scenarios according to the needs of the application layer, that is, it only implements some interfaces in the RestConf specification and cannot realize the full range of business scenarios.

[0070] In response to the above-mentioned problems existing in the prior art, the present application provides a model mapping method, apparatus, device, and storage medium for SDN. The inventive concept of the SDN model mapping method provided in the present application is to obtain the corresponding service callback point associated with the service request from the multiple customized service callback points in response to the service request reported by the service device, determine the associated service callback point as each target service callback point, and use each target service callback point as the starting point of the model mapping process to achieve north-south model mapping in the SDN architecture. First, a service instance corresponding to each target service callback point is generated, and then each expected service model is obtained based on each service instance. Then, each expected configuration model is obtained based on each expected service model through the service callback function of each target service callback point. Then, each expected configuration model is compared with each current configuration model to obtain the difference between the two, that is, each difference configuration model is obtained. Then, each difference configuration model is sent to the southbound device to complete the north-south model mapping process of the SDN architecture, so that the southbound device implements the configuration model change according to each difference configuration model. Each current configuration model can be obtained based on the current service model of each service instance by triggering the service callback function of each target service callback point. It can be seen that the SDN model mapping method provided in this application only requires a small amount of secondary development code, such as customizing business callback points and writing business callback functions. By executing the model mapping method, the automatic deduction and mapping of north-south interfaces can be realized, thereby automatically realizing a full range of business scenarios and enabling the SDN controller to quickly respond to business needs, which is conducive to the rapid deployment and implementation of new businesses.

[0071] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present application. Figure 1 As shown, the SDN controller can be, for example, an electronic device 100 configured to execute the SDN model mapping method provided in the embodiment of the present application. The SDN controller is deployed in the control layer of the SDN architecture, and the controller is used to manage the global network. The business device 200 is deployed in the application layer of the SDN architecture. The application layer can focus on network business logic development and be responsible for resource orchestration. The southbound device 300 is deployed in the infrastructure layer of the SDN architecture. The infrastructure layer includes various network devices to be responsible for data forwarding. The southbound device 300 is a general term for various network devices, and the business device 200 is a general term for various business systems in the application layer.

[0072] The service device 200 sends a service request to the electronic device 100. The electronic device 100 responds to the service request by executing the SDN model mapping method provided in the embodiment of the present application, thereby automatically deducing and mapping the north-south interface. The embodiment of the present application does not limit the content of the specific service model involved in the service request.

[0073] The electronic device 100 and the business device 200 can be computers, laptops, servers, server clusters, etc. Figure 1 In the example, electronic device 100 and service device 200 are computers. This embodiment of the application does not limit the device types of electronic device 100 and service device 200. Southbound device 300 can be a network device. The specific type of network device is determined based on the actual service scenario and is not limited in this embodiment of the application.

[0074] It should be noted that the SDN model mapping method, apparatus, device, and storage medium provided in the embodiments of the present application include but are not limited to the above-mentioned application scenarios.

[0075] Figure 2 A flow chart of a SDN model mapping method provided in an embodiment of the present application. Figure 2 As shown, the SDN model mapping method provided in the embodiment of the present application includes:

[0076] S101: Customize multiple service callback points.

[0077] The business callback point will be the starting point of the model mapping process. A business model can define multiple business callback points, but in some embodiments, each business callback point may only be related to one business instance of a tenant.

[0078] In order to improve the efficiency of the model mapping process, it is necessary to reasonably plan the granularity of the service callback points. If the granularity of the service callback points is too large, that is, the higher the level of the Yang model they are in, the lower the efficiency of each model mapping process; and if the granularity of the service callback points is too small, that is, the lower the level of the Yang model they are in, the more times the model mapping process is triggered, resulting in lower efficiency of the overall model mapping process. It can be seen that the granularity of the service callback points is positively correlated with the level of the Yang model of the SDN architecture. The actual content of the granularity is determined by the level of the Yang model in the actual working conditions, and this embodiment of the application does not limit this.

[0079] The model mapping process is implemented according to multiple customized business callback points. The model mapping process only focuses on the business instance corresponding to the current business callback point, thereby mapping the business instance into the configuration model of the southbound device. Among them, the business model of each business callback point is business data with complete data. Optionally, in some embodiments, it is necessary to verify the logical integrity of the business model corresponding to the business instance when executing the model mapping process. The business model of a business callback point may be mapped into one or more configuration models by executing the model mapping method provided in the embodiment of the present application, and each configuration model needs to be associated with the business instance of the business callback point.

[0080] S102: Receive a service request reported by a service device through a RestConf interface.

[0081] The service device submits a service request to the SDN controller through the RestConf interface (called the northbound interface). Correspondingly, the SDN controller receives the service request reported by the service device through the RestConf interface.

[0082] S103: Acquire each service callback point associated with the service request from multiple service callback points according to the service request, and determine each associated service callback point as each target service callback point.

[0083] After receiving the business request, one or more business callback points associated with the business request are obtained from the customized multiple business callback points in response to the business request, and each of the obtained associated business callback points is determined as each target business callback point. It can be seen that the target business callback point can be one or more.

[0084] Based on steps S101 to S103 , each target service callback point can be obtained in response to the service request reported by the service device, and each target service callback point is used as the starting point of the model mapping process.

[0085] In one possible design, in step S103, obtaining possible implementations of each service callback point associated with the service request from multiple service callback points according to the service request includes:

[0086] According to the service path carried in the service request and in accordance with the traversal algorithm, each service callback point associated with the current service request is searched from multiple service callback points, wherein the traversal algorithm includes a downlink traversal algorithm and an uplink traversal algorithm.

[0087] Specifically, the service request (HTTP) reported by the service device carries a method, path, and body. The downward traversal algorithm refers to searching for customized service callback points step by step along the HTTP path (service path) toward the bottom of the Yang model. If a service callback point is found, the search for service callback points at the same level will continue. If at least one service callback point is found, the search will be exited. If no service callback point is found, the upward traversal algorithm will be continued. The upward traversal algorithm refers to searching for service callback points step by step along the HTTP path (service path) toward the top of the Yang model (including the current service callback point). If a service callback point is found, the search will be terminated. If no service callback point is found, the traversal algorithm will not be triggered. Therefore, each service callback point searched by the traversal algorithm is each service callback point associated with the service request, and each associated service callback point is determined as each target service callback point.

[0088] Optionally, in some embodiments, the SDN controller verifies the validity of the body data based on the Yang template using the RestConf specification. For create operations (HTTP method POST (create request)), the body data belongs to a child node of the path and does not exist in the current configuration model, thus preventing the creation of an existing service instance. For modify operations (HTTP method PATCH (incremental modification) or PUT (full modification)), the body data corresponds to the path.

[0089] S104: Generate a service instance corresponding to each target service callback point.

[0090] For each service callback point found, a corresponding service instance Ni is generated, where i = 1..n, and n is the number of target service callback points. For example, in the downlink traversal algorithm, if a service callback point is found, the child node data corresponding to the body is used as the service instance of the service callback point; in the uplink traversal algorithm, if a service callback point is found, the body data is used as the service instance of the service callback point.

[0091] S105: Generate each expected business model according to each business instance and the current business model of each business instance.

[0092] After obtaining each business instance Ni, each expected business model Ei is generated based on each business instance Ni and the current business model Ci of each business instance. The expected business model is the business model after the change desired based on the business request. It should be noted that the business model in the embodiment of the present application is implemented by the Yang model.

[0093] In one possible design, step S105 may be implemented as follows: Figure 3 shown. Figure 3 The present invention provides a flow chart of generating an expected business model. Figure 3 As shown, the embodiment of the present application includes:

[0094] S1051: According to the path of each business instance, query the current business model of each business instance from the preset database.

[0095] S1052: Merge each business instance with the current business model of each queried business instance to obtain each expected business model.

[0096] The SDN controller queries the current business model Ci of each business instance from the preset database based on the path of the business instance Ni of each target business callback point sent by the northbound interface, merges each business instance Ni and Ci respectively, and generates each corresponding expected business model Ei.

[0097] Specifically, when merging, the model merging algorithm is used. Different types of business requests issued by the northbound interface correspond to different model merging algorithms. The model merging algorithms can include at least one of the following: a merging algorithm for create requests, a merging algorithm for incremental modification requests, a merging algorithm for full modification requests, and a merging algorithm for deletion requests. The specific model merging algorithm used during the merging is determined by the business request.

[0098] The model merging algorithm is as follows:

[0099] (1) Create a merging algorithm corresponding to a request (POST): Based on the result of searching for the service callback point, if the HTTP path is the parent node of the service instance Ni or the paths of the two are the same, the service instance is directly converted into the expected service model Ei; if the HTTP path is the child node of the service instance Ni, the child model corresponding to the path in the service instance Ni is directly added to the current service model Ci to obtain the expected service model Ei. The operation of this merging algorithm can ensure that the service instance Ni will not conflict with the current service model Ci.

[0100] (2) Incremental modification (PATCH) corresponding merging algorithm: The business instance Ni is merged with the current business model Ci in an incremental manner. That is, if the business instance Ni and the current business model Ci have overlapping parts, the data in the business instance Ni is used to overwrite the data in the current business model Ci. For the non-overlapping parts, the current business model Ci is used as the standard, thus obtaining the expected business model Ei;

[0101] (3) Full modification (PUT) corresponding merging algorithm: If the HTTP path is the parent node of the business instance Ni or the paths of the two are the same, the business instance Ni is directly converted to the expected business model Ei; if the HTTP path is the child node of the business instance Ni, the sub-model corresponding to the path in the business instance Ni directly overwrites the sub-model corresponding to the path in the current business model Ci, and the rest of the parts are based on the current business model Ci to obtain the expected business model Ei;

[0102] (4) Merging algorithm corresponding to the delete request (DELETE): If the HTTP path is the parent node of the business instance Ni or the paths of the two are the same, the expected business model Ei is empty; if the HTTP path is the child node of the business instance Ni, the child model corresponding to the path is directly deleted from the current business model Ci to generate the expected business model Ei.

[0103] S106: Triggering the service callback function of each target service callback point to generate each expected configuration model according to each expected service model.

[0104] For each expected service model Ei, the SDN controller triggers the service callback function of each corresponding target service callback point and generates each corresponding expected configuration model Di.

[0105] S107: For the current business model of each business instance, trigger the business callback function of each corresponding target business callback point to generate each current configuration model.

[0106] The SDN controller triggers the service callback function of each corresponding target service callback point for the current service model Ci of each current service instance, and generates each corresponding current configuration model Fi.

[0107] Among them, each expected business model Ei and each current business model Ci are complete business instance data. When the corresponding business callback function is triggered, the business callback function is unaware of the specific differences between the expected business model and the current business model. The same mapping logic will be used for north-south model mapping, and finally different configuration models will be generated according to different northbound business models.

[0108] It should be noted that the small amount of secondary development code required for the embodiment of the present application includes writing business callback functions.

[0109] From the above description, it can be seen that the model mapping process provided in the embodiment of the present application simplifies the writing of model mapping logic, and in the model mapping process only focuses on how to map a complete northbound business model into a complete southbound configuration model.

[0110] S108: Compare each expected configuration model with each current configuration model to obtain each difference configuration model.

[0111] After obtaining each expected configuration model Di and each current configuration model Fi, each expected configuration model Di and each current configuration model Fi may be compared one by one to obtain the difference between the two, that is, to obtain each corresponding difference configuration model Hi.

[0112] S109: Send each differential configuration model to the southbound device, so that the southbound device implements the configuration model change according to each differential configuration model.

[0113] The SDN controller sends each differential configuration model Hi to the southbound device. The southbound device then changes the southbound configuration model of the current configuration model it executes based on each differential configuration model Hi, thereby using the changed configuration model to respond to the service request of the service device.

[0114] The north-south model mapping process in the SDN model mapping method described in the above example can be as follows: Figure 4 As shown. Through the description of the above embodiments, it can be seen that the SDN model mapping method provided by the embodiment of the present application provides an SDN model automatic mapping mechanism. Based on the automatic mapping mechanism, only a small amount of secondary development code is required, such as defining business callback points and writing business callback functions, to achieve automatic deduction and mapping of north-south interfaces, thereby quickly responding to business needs. There is no existing technology in which, during the actual project implementation, the SDN controller only implements part of the interfaces in the RestConf specification according to the needs of the application layer to customize part of the business scenarios. Instead, the full range of business scenarios can be automatically realized through the automatic mapping mechanism, which is convenient for rapid deployment and implementation of new businesses.

[0115] In some embodiments, the service model implemented by the Yang model may include an l3vpn-svc service model. The following describes the SDN model mapping method provided in the embodiments of the present application using the l3vpn-svc model:

[0116] Figure 5 This is a schematic diagram of the structure of a l3vpn-svc model provided in an embodiment of the present application. Figure 5 As shown in the figure, the service data of l3vpn-svc is used as the instance data. The service model currently includes a vpn-svc instance vpn1 and two site instances site1 and site2. Site2 includes two access instances ac1 and ac2.

[0117] In the Ietf-l3vpn-svc YANG model, the core service instance objects are vpn-svc and site. vpn-svc is a list type that represents VPN service information for multiple tenants; site is a list type that represents service information for multiple sites. Each site establishes a many-to-one reference relationship with a vpn-svc instance.

[0118] 1. Customize business callback points and business callback function logic:

[0119] Based on the service characteristics of L3VPN-SVC, two callback points can be customized: the vpn-svc node and the site node. The vpn-scv node primarily defines the global properties of the VPN, including sub-nodes such as cloud-access, mpls, constraints, and vpn-extranet. The site node primarily defines site properties. A site contains multiple access circuits, each of which contains detailed configuration parameters such as bearer, routing-protocol, service, and connectin. As needed for this example, the two nodes device and interface can be expanded under the requested-type subnode of the beaer node to define the network element and port corresponding to the access circuit.

[0120] Taking the business callback point of the site node as an example, the logic describing the model mapping is as follows:

[0121] (1) For each access under the site, process it cyclically. Each access corresponds to a YANG model of a southbound device.

[0122] (2) Convert the sub-nodes under each access into the corresponding southbound configuration model. Beaer defines the device, port and other information, and loads the relevant southbound device template according to the Beaer node; routing-protocol defines the routing protocol information of the access circuit, and the service parameters of the sub-node are mapped to the bgp and vrf parameters in the device configuration; service defines the qos-related parameters of the access circuit, and the service parameters will be mapped to the bw / mtu and other parameters in the device configuration; connection defines the interconnection address information of the access circuit, and the service parameters will be mapped to the interface ip and bgp neighbor and other parameters in the device configuration. (3) Finally, two southbound device Yang models will be generated as follows Figure 6 As shown, the southbound device model, that is, the southbound configuration model, comes from the mapping of the northbound business model.

[0123] 2. Model mapping process

[0124] (1)RestConf interface

[0125] Assume that the northbound RestConf service request is as follows:

[0126]

[0127] According to the RestConf specification, this request is a service modification request, which is mainly used to change the interconnection address of access circuit ac2 of site sites to 192.168.1.1.

[0128] (2) Business callback point traversal

[0129] According to the RestConf request, the service callback points are traversed and a service callback point is found at http: / / restconf / data / ietf-l3vpn-svc:l3vpn-svc / sites / site=site2, which is the target service callback point. The service instance N' of the target service callback point is generated:

[0130]

[0131]

[0132] (3) Load the current business model C' of the business callback point in the Yang repository (preset database):

[0133]

[0134]

[0135] (4) Business instance N' is merged with the current business model C' to generate the expected business model E':

[0136] Based on the current service model C', the provided-address is currently configured as 192.168.1.1. In this northbound service instance, the provided-address is configured as 192.168.1.3. Therefore, after the two models are merged, the provided-address value is replaced with 192.168.1.3. The mask value is the same as the current value, so it is not modified.

[0137]

[0138]

[0139] (5) The service callback function is triggered, and the current service model C' is mapped to the current southbound configuration model F':

[0140] The north-south parameter mapping relationship is shown in Table 1 below:

[0141] Table 1

[0142]

[0143]

[0144] The current configuration model F' is obtained as follows:

[0145]

[0146]

[0147] (6) The service callback function is triggered, and the expected service model E' is mapped into the southbound expected configuration model D':

[0148] The mapping logic of the expected business model E' is the same as that of the current business model D'. As above, the expected configuration model D' is obtained as follows:

[0149]

[0150] (7) Compare the expected configuration model D' with the current configuration model F' to generate a difference configuration model H':

[0151]

[0152] The final comparison result indicates that the interface address needs to be modified. This result is pushed to the southbound device ne1 via the southbound Yang model interface, thus completing the model mapping process. It should be noted that the above description is only based on the l3vpn-svc model as an example, and does not limit the business models that can be implemented by the Yang model in the SDN model mapping method provided in the embodiments of this application.

[0153] Figure 7 This is a structural diagram of an SDN model mapping device provided in an embodiment of the present application. Figure 7 As shown, the SDN model mapping device 400 provided in an embodiment of the present application includes:

[0154] The acquisition module 401 is used to obtain each target service callback point in response to the service request reported by the service device. Each target service callback point is the starting point of the model mapping process. The service device is deployed in the application layer of the SDN architecture;

[0155] The first processing module 401 is used to generate a business instance corresponding to each target business callback point, and generate each expected business model based on each business instance and the current business model of each business instance;

[0156] The second processing module 403 is configured to trigger the service callback function of each target service callback point to generate each expected configuration model according to each expected service model, and compare each expected configuration model with each current configuration model to obtain each difference configuration model;

[0157] The sending module 404 is used to send each differential configuration model to the southbound device, so that the southbound device implements the configuration model change according to each differential configuration model. The southbound device is deployed at the infrastructure layer of the SDN architecture.

[0158] In one possible design, the acquisition module 401 is configured to:

[0159] Customize multiple service callback points. The granularity of service callback points is positively correlated with the Yang model hierarchy of the SDN architecture.

[0160] Receive business requests reported by business devices through the RestConf interface;

[0161] Each service callback point associated with the service request is obtained from a plurality of service callback points according to the service request, and each associated service callback point is determined as a target service callback point.

[0162] In one possible design, the acquisition module 401 is further configured to:

[0163] According to the business path carried by the business request, a traversal algorithm is used to search for each business callback point associated with the current business request from multiple business callback points;

[0164] The traversal algorithm includes a downward traversal algorithm and an upward traversal algorithm.

[0165] In one possible design, the first processing module 402 is configured to:

[0166] According to the path of each business instance, the current business model of each business instance is queried from the preset database;

[0167] Each business instance is merged with the current business model of each queried business instance to obtain each expected business model.

[0168] In one possible design, the first processing module 402 is further configured to:

[0169] Merge each business instance with the current business model of each queried business instance according to the model merging algorithm;

[0170] Among them, the model merging algorithm includes at least one of a merging algorithm corresponding to a creation request, a merging algorithm corresponding to an incremental modification request, a merging algorithm corresponding to a full modification request, and a merging algorithm corresponding to a deletion request.

[0171] In one possible design, the second processing module 403 is configured to:

[0172] For the current business model of each business instance, the business callback function of each corresponding target business callback point is triggered to generate each current configuration model.

[0173] In one possible design, the second processing module 403 is further configured to:

[0174] Each expected configuration model is compared with each current configuration model one by one to obtain each difference configuration model.

[0175] In one possible design, the business model implemented by the Yang model includes the l3vpn-svc model.

[0176] The SDN model mapping device provided in the embodiment of the present application can execute the corresponding steps of the SDN model mapping method in the above method embodiment. Its implementation principles and technical effects are similar and will not be repeated here.

[0177] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device 500 may include: a processor 501 and a memory 502 communicatively connected to the processor 501 .

[0178] The memory 502 is used to store programs. Specifically, the programs may include program codes, and the program codes include computer-executable instructions.

[0179] The memory 502 may include a high-speed RAM memory, and may also include a non-volatile memory (NoN-volatile memory), such as at least one disk memory.

[0180] The processor 501 is configured to execute the computer-executable instructions stored in the memory 502 to implement the various steps in the SDN model mapping method in the above embodiment.

[0181] The processor 501 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0182] Optionally, the memory 502 may be independent or integrated with the processor 501. When the memory 502 is a device independent of the processor 501, the electronic device 500 may further include:

[0183] Bus 503 is used to connect processor 501 and memory 502. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc., but this does not mean that there is only one bus or only one type of bus.

[0184] Optionally, in a specific implementation, if the memory 502 and the processor 501 are integrated on a chip, the memory 502 and the processor 501 can communicate through an internal interface.

[0185] The present application also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores computer execution instructions, and the computer execution instructions are used for each step of the method in the above embodiment.

[0186] The present application also provides a computer program product, including computer-executable instructions, which implement the various steps of the method in the above embodiment when executed by a processor.

[0187] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered merely as exemplary, and the true scope and spirit of the present application are indicated by the claims.

[0188] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A SDN model mapping method, characterized in that: include: Responding to a service request reported by a service device, obtaining each target service callback point, wherein each target service callback point is a starting point of a model mapping process, and the service device is deployed in the application layer of the SDN architecture; Generate a service instance corresponding to each target service callback point, and generate each expected service model based on each service instance and the current service model of each service instance; triggering a service callback function of each target service callback point to generate each expected configuration model according to each expected service model, and comparing each expected configuration model with each current configuration model to obtain each difference configuration model; Each of the differential configuration models is issued to a southbound device, so that the southbound device implements a configuration model change according to each of the differential configuration models, and the southbound device is deployed at an infrastructure layer of the SDN architecture.

2. The model mapping method according to claim 1, characterized in that: The step of obtaining each target service callback point in response to the service request reported by the service device includes: Customize multiple service callback points, where the granularity of the service callback points is positively correlated with the Yang model hierarchy of the SDN architecture; Receiving the service request reported by the service device through the RestConf interface; Each service callback point associated with the service request is obtained from the multiple service callback points according to the service request, and each associated service callback point is determined as each target service callback point.

3. The model mapping method according to claim 2, characterized in that: The acquiring, according to the service request, each service callback point associated with the service request from the multiple service callback points includes: Searching for each service callback point associated with the current service request from the multiple service callback points according to the service path carried by the service request and using a traversal algorithm; The traversal algorithm includes a downlink traversal algorithm and an uplink traversal algorithm.

4. The model mapping method according to claim 3, characterized in that: Generating each expected business model according to each business instance and the current business model of each business instance includes: According to the path of each business instance, query the current business model of each business instance from a preset database; Each business instance is merged with the queried current business model of each business instance to obtain each expected business model.

5. The model mapping method according to claim 4, characterized in that: The merging of each business instance with the queried current business model of each business instance includes: Merging each business instance with the queried current business model of each business instance according to a model merging algorithm; The model merging algorithm includes at least one of a merging algorithm corresponding to a creation request, a merging algorithm corresponding to an incremental modification request, a merging algorithm corresponding to a full modification request, and a merging algorithm corresponding to a deletion request.

6. The model mapping method according to claim 4, characterized in that: Before comparing each expected configuration model with each current configuration model to obtain each difference configuration model, the method further includes: For the current business model of each business instance, the business callback function of each corresponding target business callback point is triggered to generate each current configuration model.

7. The model mapping method according to any one of claims 1 to 6, characterized in that: The comparing each expected configuration model with each current configuration model to obtain each difference configuration model includes: Each of the expected configuration models is compared with each of the current configuration models one by one to obtain each of the difference configuration models.

8. The model mapping method according to claim 2, characterized in that: The business model implemented by the Yang model includes the l3vpn-svc model.

9. A SDN model mapping device, characterized in that: include: An acquisition module is configured to acquire each target service callback point in response to a service request reported by a service device, wherein each target service callback point is a starting point of a model mapping process, and the service device is deployed in the application layer of the SDN architecture; A first processing module is configured to generate a service instance corresponding to each target service callback point, and generate each expected service model according to each service instance and the current service model of each service instance; A second processing module is configured to trigger a service callback function of each target service callback point to generate each expected configuration model according to each expected service model, and compare each expected configuration model with each current configuration model to obtain each difference configuration model; The sending module is used to send each differential configuration model to the southbound device, so that the southbound device implements the configuration model change according to each differential configuration model. The southbound device is deployed in the infrastructure layer of the SDN architecture.

10. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the SDN model mapping method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the SDN model mapping method as described in any one of claims 1 to 8.

Images