Patent Publication Number: US-2022231909-A1

Title: Plug-in generation device, controller, plug-in generation method, and plug-in generation program

Description:
TECHNICAL FIELD 
     The present invention relates to a plugin generation device, a controller, a plugin generation method, and a plugin generation program. 
     BACKGROUND ART 
     Software-defined networking (SDN) is a concept that enables flexible virtualization of networks. This allows a service provider to procure adequate network resources as needed from a network provider. An SDN controller is a device that receives an instruction from a service provider application, and controls a physical network device of the network provider. 
     A northbound interface (NBI) in the SDN controller is a service model responsible for the interface with the application. 
     A southbound interface (SBI) in the SDN controller is a device model responsible for the interface with the network device. 
     With this arrangement, the application transmits a control command for a network device to the service model, and the network device receives the control command from the device model. The control command is an operation for inputting a config (network device settings information), for example. Patent Literature 1 describes how a config with existing settings is migrated to another device. 
     As a development environment (framework) for such an SDN controller, model-driven frameworks like the following exist.
     “OpenDaylight” described in Non-Patent Literature 1   “Open Networking Operating System (ONOS)” described in Non-Patent Literature 2   “Network Services Orchestrator (NSO)” described in Non-Patent Literature 3   

     These frameworks make development easier by accepting a data model defined in a data model language such as YANG as input, and outputting a portion (a service, a datastore) of the SDN controller. 
     CITATION LIST 
     Patent Literature 
     Patent Literature 1: Japanese Patent Laid-Open No. 2018-136649 
     Non-Patent Literature 
     Non-Patent Literature 1: LF Projects, LLC, “OpenDaylight”, [online], [retrieved Jun. 13, 2019], Internet &lt;URL: https://www.opendaylight.org/&gt; 
     Non-Patent Literature 2: The ONOS Project, “ONOS is building a better network”, [online], [retrieved Jun. 13, 2019], Internet &lt;URL: https://onosproject.org/&gt; 
     Non-Patent Literature 3: Cisco Systems, Inc., “Cisco Network Services Orchestrator  4 . 7 ”, [online], Jun. 14, 2018 [retrieved Jun. 13, 2019], Internet &lt;URL: https://www.cisco.com/c/ja_jp/support/cloud-systems-management/network-services-orchestrator-4-7/model.html&gt; 
     SUMMARY OF THE INVENTION 
     Technical Problem 
     In the frameworks of the related art described above, the service framework in the SDN controller is generated automatically, but a developer needs to develop the internal processing logic separately as a plugin. The processing logic written in a plugin defines a mapping between the service model and the device model, such as from which service model to which device model the config is input. This mapping between models is an important step in the process of developing an SDN app. Note that some operations of inputting a config do not include complex logic such as setting a loopback address, while others include complex logic for traffic engineering (TE) such as granting an exclusive band and a delay budget to a specific flow as a policy, for example. 
       FIG. 19  is a simplified diagram of mappings between models. For example, from three service models (NBI A, B, and C) and three device models (SBI A, B, and C), a first mapping from “NBI A” to “SBI A” and a second mapping from “NBI B” to “SBI C” are created.  FIG. 20  is a configuration diagram of an SDN controller that embodies the mappings between models in  FIG. 19 . A plugin A of a service A embodying “NBI A” relays instructions from a datastore A to the device model “SBI A” as the first mapping. 
     A plugin B of a service B embodying “NBI B” and a plugin C of a service C embodying “NBI C” relay instructions from a datastore C to the device model “SBI C” as the second mapping. 
       FIG. 21  is a diagram illustrating the problem of the number of mappings between models. The number of mappings between models is the number of combinations of a service model and a device model. For example, in a controller model  200 , if five service models “A” to “E” in a service definition  201  and four device models “ 1 ” to “ 4 ” in a device definition  203  are combined, the number of mappings is 5×4=20 (the number of arrows indicated by the sign  202 ). 
     Consequently, the developer needs to prepare  20  mapping definition files individually, and even if the processing logic of each one is simple, the increase in the number of mappings itself is a heavy burden. Particularly, in the case of constructing a multi-vendor system, the device models of a variety of vendors need to be handled individually, and the number of mappings also increases. 
     Note that although the framework of the related art assists with the generation of service models and device models, assistance for reducing the burden of the mappings between models is not provided. For this reason, the developer feels a heavy burden in the step of developing the mappings between models. 
     Accordingly, a major issue addressed by the present invention is reducing the burden of developing mappings between services and devices when a plurality of services control a plurality of network devices. 
     Means for Solving the Problem 
     To address the issue, a plugin generation device of the present invention has the following features. The present invention includes: a mapping loading unit that loads, into a controller that transmits instruction information with respect to a network device from a service model that receives the instruction information to a device model that notifies the network device of the received instruction information, first mapping information between the service model and a common model and second mapping information between the common model and the device model as information for mapping the service model and the device model, respectively; 
     a config loading unit that loads preconditions for generating a plugin as config information; 
     a plugin generation unit that generates a plugin to be incorporated into the controller on the basis of the first mapping information, the second mapping information, and the config information; and 
     a plugin output unit that outputs the created plugin to the controller, and thereby causes the controller to execute a process of transmitting the instruction information according to the first mapping information and the second mapping information. 
     Effects of the Invention 
     According to the present invention, it is possible to reduce the burden of developing mappings between services and devices when a plurality of services control a plurality of network devices. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  is a configuration diagram of a plugin generation device according to the present embodiment. 
         FIG. 2  is a hardware configuration diagram of the plugin generation device according to the present embodiment. 
         FIG. 3  is a configuration diagram of a controller model according to the present embodiment. 
         FIG. 4  is a configuration diagram illustrating an example of the controller model in  FIG. 3  according to the present embodiment. 
         FIG. 5  is a diagram illustrating a mapping definition file in YANG notation for a single service model according to the present embodiment. 
         FIG. 6  is a diagram illustrating the mapping definition file of  FIG. 5  in tree notation according to the present embodiment. 
         FIG. 7  is a diagram illustrating a mapping definition file in YANG notation for a single common model according to the present embodiment. 
         FIG. 8  is a diagram illustrating the mapping definition file of  FIG. 7  in tree notation according to the present embodiment. 
         FIG. 9  is a diagram illustrating a mapping definition file in YANG notation for a single device model according to the present embodiment. 
         FIG. 10  is a diagram illustrating the mapping definition file of  FIG. 9  in tree notation according to the present embodiment. 
         FIG. 11  is a diagram illustrating a mapping definition file of first mapping information in tree notation according to the present embodiment. 
         FIG. 12  is a diagram illustrating a mapping definition file of second mapping information in tree notation according to the present embodiment. 
         FIG. 13  is a configuration diagram illustrating a controller as a class model according to the present embodiment. 
         FIG. 14  is a sequence diagram illustrating a process by the plugin generation device according to the present embodiment. 
         FIG. 15  is a configuration diagram illustrating an object model of the controller according to the present embodiment. 
         FIG. 16  is a sequence diagram mainly illustrating a process by a service A management unit according to the present embodiment. 
         FIG. 17  is a sequence diagram mainly illustrating a process by a common model management unit according to the present embodiment. 
         FIG. 18  is a sequence diagram mainly illustrating a process by a device C management unit according to the present embodiment. 
         FIG. 19  is a simplified diagram of mappings between models. 
         FIG. 20  is a configuration diagram of an SDN controller that embodies the mappings between models in  FIG. 19 . 
         FIG. 21  is a diagram illustrating the problem of the number of mappings between models. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     Hereinafter, an embodiment of the present invention will be described in detail and with reference to the drawings. 
       FIG. 1  is a configuration diagram of a plugin generation device  10 . 
     The plugin generation device  10  includes a mapping loading unit  11 , a config loading unit  12 , a plugin generation unit  13 , and a plugin output unit  14 . The mapping loading unit  11  loads a mapping definition file containing information about mappings between models (for details, see  FIGS. 5 to 12 ), and transmits the loaded mapping information to the plugin generation unit  13 . 
     The config loading unit  12  loads config information indicating common preconditions for generating a plugin from a config file, and transmits the loaded config information to the plugin generation unit  13 . In the config information, the following information is stated as the preconditions, for example.
     The class of plugin to generate (a service model—common model plugin, or a device model—device model plugin)   A common model used by the plugin to generate   The format of the file in which the plugin is output (such as a Java(R) file or a py file)   A process when outputting the plugin (for example, a process of installing or updating a feature based on the Open Service Gateway Initiative (OSGi) architecture) The plugin generation unit  13  accepts mapping information and config information as input, and generates a plugin. The plugin is a program that executes a mapping between models on the basis of the mapping information.   

     The plugin output unit  14  converts the generated plugin to a format specified by the config, and outputs to a controller  20  ( FIG. 13 ). On the other hand, in the case where the plugin is not generated successfully, null is returned to the controller  20 . 
       FIG. 2  is a hardware configuration diagram of the plugin generation device  10 . 
     The plugin generation device  10  is configured as a computer  900  including a CPU  901 , RAM  902 , ROM  903 , an HDD  904 , a communication I/F  905 , an input/output I/F  906 , and a media I/F  907 . 
     The communication I/F  905  is connected to an external communication device  915 . The input/output I/F  906  is connected to an input/output device  916 . The media I/F  907  reads and writes data with respect to a recording medium  917 . Furthermore, the CPU  901  controls each processing unit by executing a program (also referred to as an application, which may be abbreviated to app) loaded into the RAM  902 . Additionally, the program may also be distributed through a communication channel or by being recorded onto a recording medium  917  such as CD-ROM. 
       FIG. 3  is a configuration diagram of a controller model  210 . 
     The controller model  210  is an abstract data representation modeling the controller  20  ( FIG. 13 ) as an SDN controller. In the controller model  210 , service models  211 , a common model  212 , and device models  213  are mapped. 
     Here, the “common model  212 ” is newly introduced between the service models  211  and the device models  213  in the controller  20  as a mechanism that reduces the burden of mapping between models while also utilizing the framework of a model-driven SDN controller. 
     In other words, a model-driven SDN controller has a one-stage mapping in which the service models  211  and the device models  213  are mapped directly. On the other hand, in the present embodiment, the mapping is expanded into a two-layer mapping including a first-stage mapping between the service models  211  and the common model  212 , and a second-stage mapping between the common model  212  and the device models  213 . 
     In this way, the service models  211  are mapped to the common model  212  without being mapped directly to the device models  213 . Because the service provider does not have to create mappings to the device models  213  not under direct management by the service provider itself, the burden of creating mapping definition files is reduced. 
     Similarly, the device models  213  are mapped to the common model  212  without being mapped directly to the service models  211 . Because the network provider does not have to create mappings to the service models  211  not under direct management by the network provider itself, the burden of creating mapping definition files is reduced. With this arrangement, if five service models  211  and four device models  213  are combined, the number of mappings is only 5+4=9, a reduction from the 20 mappings in  FIG. 21 . 
       FIG. 4  is a configuration diagram illustrating an example of the controller model  210  in  FIG. 3 . In a controller model  210   b  obtained by extracting a portion of the controller model  210  in  FIG. 3 , a service model  211   b,  a common model  212   b,  and a device model  213   b  are mapped. Hereinafter,  FIGS. 5 to 12  will be referenced to give an example of a specific mapping definition file of each model in the controller model  210   b.  These mapping definition files are input as input data into the plugin generation device  10  by a provider or the like. 
       FIG. 5  is a diagram illustrating a mapping definition file in YANG notation for a single service model. 
       FIG. 6  is a diagram illustrating the mapping definition file of  FIG. 5  in tree notation. The mapping definition file contains an assignment of an interface name “1o0” and an address “10.101.1.21/32” as a loopback interface. For example, “1o-dev1” outlined in bold in the element “name” in  FIG. 5  corresponds to the row A 03  in  FIG. 6 . Also, a key for specifying the device to be mapped is stated as the element “mng-addr” in  FIG. 5  and the row A 06  in  FIG. 6 . 
     On the other hand, although omitted from illustration, a mapping file including the four basic arithmetic operations may also be used, such as by defining a parameter “dev-id” of the service model and setting the loopback setting parameter (ip-addr) to “1.1. (dev-id+100).1”. 
       FIG. 7  is a diagram illustrating a mapping definition file in YANG notation for a single common model. 
       FIG. 8  is a diagram illustrating the mapping definition file of  FIG. 7  in tree notation. The tree notation is an extraction of only the loopback setting portion, and in actuality, other setting portions are also included. For example, the element “name” in  FIG. 7  corresponds to the row B 03  in  FIG. 8 . Also, the element “index” in  FIG. 7  corresponds to the row B 06  in  FIG. 8 . 
       FIG. 9  is a diagram illustrating a mapping definition file in YANG notation for a single device model. 
       FIG. 10  is a diagram illustrating the mapping definition file of  FIG. 9  in tree notation. The tree notation is an extraction of only the loopback setting portion, and in actuality, other setting portions are also included. For example, the element “name” in  FIG. 9  corresponds to the row CO 2  in  FIG. 10 . 
       FIG. 11  is a diagram illustrating a mapping definition file of first mapping information in tree notation. 
     This mapping definition file is obtained by applying the parameters in the mapping definition file for a single service model in  FIG. 6  to the mapping definition file for a single common model in  FIG. 8 . In other words, by applying parameters in a higher layer to messages in a lower layer, a provider creates first mapping information to be treated as input data for the plugin generation device  10 . 
     The contents of the row D 04  and the row D 10  are changed after application. Note that the row DO 1  indicates that the mapping definition file is between a service model  211  and the common model  212 . 
       FIG. 12  is a diagram illustrating a mapping definition file of second mapping information in tree notation. 
     This mapping definition file is obtained by applying the parameters in the mapping definition file for a single common model in  FIG. 8  to the mapping definition file for a single device model in  FIG. 10 . Like  FIG. 11 , by applying parameters in a higher layer to messages in a lower layer, a provider creates second mapping information to be treated as input data for the plugin generation device  10 . 
     The contents of the row E 03  and the row E 06  are changed after application. Note that the row E 01  indicates that the mapping definition file is between the common model  212  and a device model  213 . 
       FIG. 13  is a configuration diagram illustrating the controller  20  as a class model  20   a.    
     The controller  20  includes a service model  21 , a common model  22   a,  and a device model  23 . 
     Like  FIG. 20 , the common model  22   a  includes services (a service A  221   a,  a common model  222   a,  a device C  223   a,  a device D  224   a,  and a device monitor  225   a ) and a datastore corresponding to each service (a datastore A  221   b,  a datastore B  222   b,  a datastore C  223   b,  a datastore D  224   b,  and a datastore E  225   b ). 
     Each service of the class model  20   a  achieves the following functions by incorporating respective plugins A to D generated by the plugin generation device  10 .
     The service A  221   a  incorporates the plugin A, and thereby provides access to an application through the service model  21 , and transmits information to the common model  222   a.      The common model  222   a  incorporates the plugin B, and thereby specifies the machine (device) that is the target of the information transmitted from the service A  221   a,  and transmits information to the specified device (the device C  223   a  or the device D  224   a ).   The device C  223   a  incorporates the plugin C, and thereby provides access to a physical network device through the device model  23  in accordance with the information transmitted from the common model  222   a.      The device D  224   a  likewise incorporates the plugin D, and thereby provides functions similar to the device C  223   a  with respect to a different network device. Furthermore, the device monitor  225   a  provided as the framework of the model-driven SDN controller stores information about the mounted network devices. This arrangement makes it possible to search for a target machine with respect to the common model  222 a.   

       FIG. 14  is a sequence diagram illustrating a process by the plugin generation device  10 . The mapping loading unit  11  loads the mapping definition file (with parameters applied) illustrated in  FIGS. 11 and 12  (S 101 ), and inputs the mapping information into the plugin generation unit  13  (S 102 ). 
     The config loading unit  12  loads a config file (S 103 ), and inputs the config information into the plugin generation unit  13  (S 102 ). 
     The plugin generation unit  13  generates a plugin for executing the mapping information on the basis of the class specified by the config information (S 105 ), and inputs information about the generated plugin into the plugin output unit  14  (S 106 ). Here, the plugin generation unit  13  generates a plugin of a different class according to the content of the mapping in the scope of predetermined logic. 
     The plugin output unit  14  calls the specified format of the config information with respect to the config loading unit  12  (S 107 ), and obtains a response (S 108 ). The plugin output unit  14  converts the plugin input in S 106  to the specified format of the config information, and then outputs to the controller  20 . 
       FIG. 15  is a configuration diagram illustrating an object model  20   c  of the controller  20 . In the object model  20   c,  the plugins input by the plugin output unit  14  are incorporated into the class model  20   a  of  FIG. 13 . A service A management unit  221   c  is obtained by incorporating the first mapping information ( FIG. 11 ) between the service A  221   a  and the common model  222   a  as the plugin A. 
     A common model management unit  222   c  is obtained by incorporating the second mapping information ( FIG. 12 ) between the common model  222   a  and a target device (the device C  223   a  or the device D  224   a ) as the plugin B. 
     A device C management unit  223   c  is obtained by incorporating the second mapping information between the common model  222   a  and a target device (the device C  223   a ) as the plugin C. 
     A device D management unit  224   c  is obtained by incorporating the second mapping information between the common model  222   a  and a target device (the device D  224   a ) as the plugin D. 
     The device C management unit  223   c  and the device D management unit  224   c  executes a management command such as a NETCONF command on the device model  23 , and determines whether the config input is successful or not from the notification result. 
     A device monitoring unit  225   c  is an execution object of the device monitor  225   a.  Also, a datastore  220   b  is a collective term for the datastore A  221   b,  the datastore B  222   b,  the datastore C  223   b,  the datastore D  224   b,  and the datastore E  225   b  in  FIG. 13 . 
     Hereinafter,  FIGS. 16 to 18  will be referenced to describe operations by the controller  20  in detail.  FIG. 16  is a sequence diagram mainly illustrating a process by the service A management unit  221   c.    
     The service model  21  transmits a message received from an application to the service A management unit  221   c  (S 201 ). Note that the content of the message conforms to the data model. 
     The service A management unit  221   c  converts the content of the received message to be compatible with the common model management unit  222   c  (S 202 ), and transmits information about the conversion result to the common model management unit  222   c  (S 203 ). 
     Note that the transmitted content in S 203  may be “Create” indicating object generation, “Update” indicating object modification, and “Delete” indicating object removal, for example. In these cases, information about the target equipment (such as an address and an equipment ID) treated as the transmission destination is included in the transmitted content. 
     Alternatively, the transmitted content may be “Get” indicating the acquisition of information in some cases. In this case, it is sufficient to query the datastore  220   b  managed by the service A management unit  221   c,  and return the information obtained by the response (not illustrated). 
     The common model management unit  222   c  processes the transmitted information (S 204 , details in  FIG. 17 ), and notifies the service A management unit  221   c  of the result (S 205 ). The service A management unit  221   c  stores the notification result of S 205  (for example, a successful process) in the datastore  220   b  (S 206 ), and also notifies the service model  21  of the notification result of S 205  (S 207 ). 
       FIG. 17  is a sequence diagram mainly illustrating a process by the common model management unit  222   c.    
     The common model management unit  222   c  receives the information transmission from the service A management unit  221   c  (S 211 , or S 203  in  FIG. 16 ), and queries the device monitoring unit  225   c  for the machine of the target equipment (S 212 ). 
     The device monitoring unit  225   c  receives the query of S 212 , and by searching the datastore  220   b  according to the machine query (S 213 ), causes a notification of the machine of the target equipment to be issued (S 214 ). Consequently, in the datastore  220   b,  an equipment management table associating an equipment ID, a management address, and a machine (model name) for each mounted (registered) network device is prepared in advance. 
     The common model management unit  222   c  receives the notification of the machine of the target equipment from the device monitoring unit  225   c  (S 215 ), and converts the information into information specifying the target equipment (network device) (S 216 ). Hereinafter, the description will continue by treating the device C  223   a  as the target equipment. Also, in S 216 , the common model management unit  222   c  may also converts the instruction content (parameters) transmitted in S 211  on the basis of a mapping definition file. 
     The common model management unit  222   c  transmits the instruction (such as Create, Update, or Delete) transmitted from the service A management unit  221   c  in S 211  to the device C management unit  223   c  of the target equipment obtained in S 216  (S 217 ), and causes the device C management unit  223   c  to process the instruction (S 218 , details in  FIG. 18 ). 
     The device C management unit  223   c  notifies the common model management unit  222   c  of the result of S 218  (S 219 ). The common model management unit  222   c  stores the notification result of S 219  (for example, a successful process) in the datastore  220   b  (S 220 ), and also notifies the service A management unit  221   c  of the notification result of S 219  (S 221 ). 
       FIG. 18  is a sequence diagram mainly illustrating a process by the device C management unit  223   c.    
     The device C management unit  223   c  receives the information transmission from the common model management unit  222   c  (S 231 , or S 217  in  FIG. 17 ), and converts the information to be compatible with the device model  23  (S 232 ). 
     The device C management unit  223   c  calls the SBI according to the information class by transmitting information about the conversion result in S 232  to the device model  23  (S 233 ). 
     The device model  23  receives the call in S 233 , and causes the instruction transmitted in S 231  (such as Create, Update, or Delete) to be processed by the network device managed by the device C management unit  223   c  (S 234 ). 
     The device C management unit  223   c  receives a notification of the result of S 234  from the device model  23  (S 235 ). Additionally, the device C management unit  223   c  stores the result notification of S 235  (for example, a successful process) in the datastore  220   b  (S 236 ), and also notifies the common model management unit  222   c  of the result notification of S 235  (S 237 ). On the other hand, in the case where the result notification of S 235  indicates failure, the process of storing in the datastore  220   b  (S 236 ) is omitted. 
     Advantageous Effects 
     A plugin generation device  10  of the present invention includes: a mapping loading unit  11  that loads, into a controller  20  that transmits instruction information with respect to a network device from a service model  21  that receives the instruction information to a device model  23  that notifies the network device of the received instruction information, first mapping information between the service model  21  and a common model  22  and second mapping information between the common model  22  and the device model  23  as information for mapping the service model  21  and the device model  23 , respectively; 
     a config loading unit  12  that loads preconditions for generating a plugin as config information; 
     a plugin generation unit  13  that generates a plugin to be incorporated into the controller  20  on the basis of the first mapping information, the second mapping information, and the config information; and 
     a plugin output unit  14  that outputs the created plugin to the controller  20 , and thereby causes the controller  20  to execute a process of transmitting the instruction information according to the first mapping information and the second mapping information. 
     With this arrangement, through the introduction of an architecture newly provided with the common model  22  as an intermediate layer, even if the number of service models  21  or the number of device models  23  increases, the first mapping information and the second mapping information are defined separately. Consequently, the total number of mappings can be reduced, and the SDN development burden can be alleviated. 
     A controller  20  of the present invention includes: a service A management unit  221   c  that receives a notification of instruction information with respect to a network device from a service model  21  that receives the instruction information, and transmits the instruction information to a common model management unit  222   c  of a common model  22  according to first mapping information between the service model  21  and the common model  22 ; 
     the common model management unit  222   c  that receives the notification of the instruction information from the service A management unit  221   c,  and transmits the instruction information to a device C management unit  223   c  of a device model  23  according to second mapping information between the common model  22  and the device model  23 ; and 
     the device C management unit  223   c  that receives the notification of the instruction information from the common model management unit  222 c, and notifies a network device of the received instruction information. 
     With this arrangement, through the introduction of an architecture newly provided with the common model  22  as an intermediate layer, even if the number of service models  21  or the number of device models  23  increases, the total number of mappings can be reduced, and therefore the operating costs of actions such as adding and updating plugins with respect to the controller  20  can be reduced. 
     REFERENCE SIGNS LIST 
       10  plugin generation device 
       11  mapping loading unit 
       12  config loading unit 
       13  plugin generation unit 
       14  plugin output unit 
       20  controller 
       21  service model 
       22  common model 
       23  device model 
       221   c  service A management unit (service management unit) 
       222   c  common model management unit 
       223   c  device C management unit (device management unit)