KR102021671B1 - A general remote procedure call as a northbound application programming interface for communication in an application layer of a software defined network - Google Patents

Abstract

According to an embodiment, a device may be a server or a terminal included in an SDN, and may transmit data transmitted between an application layer and a control layer using a gRPC protocol. More specifically, the gRPC protocol may be used as a northbound API called by the process of each of the application layer and the control layer.

Description

GRPC {A GENERAL REMOTE PROCEDURE CALL AS A NORTHBOUND APPLICATION PROGRAMMING INTERFACE FOR COMMUNICATION IN AN APPLICATION LAYER OF A SOFTWARE DEFINED NETWORK}

The present invention relates to an SDN and a device connected to the SDN.

Software Defined Network (SDN) is a network technology that makes a controller programmable by separating the controller, which is a hardware device, into the software domain. The network is controlled centrally through the control plane of the software domain. Thus, the terminal of the software defined network can perform data communication more efficiently. Furthermore, software defined networks can support fast and secure network operations by performing batch policy enforcement.

The present invention proposes a software defined network that performs communication between an application layer and a control layer using gRPC as a northbound API.

According to an embodiment, receiving a request for calling a method from an application included in an application layer, and a network service function having the method among a plurality of network service functions included in a control layer controlling a network, Forwarding the request via, receiving a result corresponding to the request from a network service function having the method, and providing the received result to the application. A communication method is provided.

According to an embodiment, the gRPC is provided with a communication method for an application layer in the SDN used as a northbound API for communication between the control layer and the application layer.

According to one embodiment, the step of forwarding the request, there is provided a communication method for an application layer in the SDN for delivering a protocol buffer (PB) message combined with the parameters included in the request to the network service function.

According to an embodiment, the receiving of the request may provide a communication method for an application layer in the SDN receiving the request based on a call of a method included in a local object of the application layer.

According to an embodiment, the receiving of the result may include providing a communication method for an application layer in the SDN receiving a result of calling a method of the network service function according to the delivered request.

According to an embodiment, receiving a request for calling a method from a network service function included in a control layer controlling a network, the application having the method among a plurality of applications belonging to an application layer and forwarding the request via a general remote procedure call (gRPC), receiving a result corresponding to the request from an application having the method, and providing the received result to the network service function. A communication method for an application layer in a software defined network (SDN) is provided.

According to one embodiment, the gRPC is provided with a communication method for an application layer in the SDN used as a Northbound API (Northbound API) for communication between the control layer and the application layer.

According to one embodiment, the step of forwarding the request, a communication method for an application layer in the SDN for delivering a PB message combined with parameters included in the request to the application.

According to an embodiment, the receiving of the request may provide a communication method for an application layer in an SDN receiving the request based on a call of a method included in a local object of the control layer.

According to an embodiment, the receiving of the result may provide a communication method for an application layer in the SDN for receiving a result of calling a method of the application according to the forwarded request.

According to one embodiment, gRPC may be used as a northbound API to perform communication between an application layer and a control layer.

FIG. 1 is a diagram conceptually illustrating a structure of an SDN layer of a device connected to an SDN using a gRPC protocol as a northbound API according to an embodiment.
FIG. 2 is an exemplary diagram for describing an operation between an application 210 and a network service function 220 of a device connected to an SDN using a gRPC protocol with a northbound API according to an embodiment.
3 is a flowchart illustrating an operation of a device connected to an SDN using a gRPC protocol with a northbound API according to an embodiment.
4 is a flowchart illustrating an operation performed by a device connected to an SDN using a gRPC protocol as a northbound API in response to a gRPC request.

Specific structural or functional descriptions of the embodiments according to the inventive concept disclosed herein are merely illustrated for the purpose of describing the embodiments according to the inventive concept, and the embodiments according to the inventive concept. These may be embodied in various forms and are not limited to the embodiments described herein.

Embodiments according to the inventive concept may be variously modified and have various forms, so embodiments are illustrated in the drawings and described in detail herein. However, this is not intended to limit the embodiments in accordance with the concept of the present invention to specific embodiments, and includes modifications, equivalents, or substitutes included in the spirit and scope of the present invention.

Terms such as first or second may be used to describe various components, but the components should not be limited by the terms. The terms are only for the purpose of distinguishing one component from another component, for example, without departing from the scope of the rights according to the inventive concept, the first component may be called a second component, Similarly, the second component may also be referred to as the first component.

When a component is said to be “connected” or “connected” to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in the middle. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between. Expressions that describe the relationship between components, such as "between" and "immediately between," or "directly neighboring to," should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, the terms “comprise” or “have” are intended to designate that the stated feature, number, step, operation, component, part, or combination thereof exists, but includes one or more other features or numbers, It is to be understood that it does not exclude in advance the possibility of the presence or addition of steps, actions, components, parts or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and are not construed in ideal or excessively formal meanings unless expressly defined herein. Do not.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings. However, the scope of the patent application is not limited or limited by these embodiments. Like reference numerals in the drawings denote like elements.

FIG. 1 is a diagram conceptually illustrating a structure of an SDN layer of a device connected to an SDN using a gRPC protocol as a northbound API according to an embodiment. The SDN layer divides the protocol design and communication used by the devices connected to the SDN into multiple layers. The device refers to a server or a terminal connected to the SDN. The structure of the SDN layer of FIG. 1 may be a high level design (HLD) structure designed based on the OpenDaylight architecture.

Referring to FIG. 1, a service, a process, or a thread running in a device connected to an SDN may be classified into any one of a plurality of layers. Referring to FIG. 1, a process of providing security services of various layers ranging from four layers to seven layers, such as operation management and monitoring of the SDN, may be executed in the application layer 110. The security service can be used to solve security problems occurring in the network. Hereinafter, a process or service executed in the application layer 110 is called an application. Referring to FIG. 1, an application controlling a graphical user interface (GUI), a virtual tenant network (VTN) coordinator, a DDoS protection, a gRPC service API, and other network applications and services are applied at an application layer 110. Can be executed. As the gRPC protocol is used as a northbound API, since an application on the server side must have an API having a method supporting a gRPC service, an API or a module for supporting a gRPC service may be included in the application layer 110.

Referring to FIG. 1, the process or service for controlling communication and policy of the SDN may be executed in the control layer 120. For example, basic network service functions such as Topology Manager, Switch Manager, Host trackers, Stats manager, Shortest path forwarding, and Distributed Overlay Virtual Ethernet (DOVE) Manager, Affinity Service, Locator / Identifier Separation Protocol (LISP), VTN Manager, Processes or services, such as Traffic Redirection, may be executed in the control layer 120. The control layer 120 may include a service abstraction layer (SAL) in which a process or service such as Plug-in Manager, Capability Abstractions, Flow programming, Inventory, or the like is executed.

Referring to FIG. 1, a process, a service, and the like that configure an infrastructure of the SDN may be executed in the infrastructure layer 130. For example, an OpenFlow Enabled Switch can be executed in the infrastructure layer 130.

The process or service executed in the control layer 120 may use an application programming interface (API) for communicating with each of the application layer 110 and the infrastructure layer 130. The API used for communication between the control layer 120 and the application layer 110 is referred to as a northbound API, and the API used for communication between the control layer 120 and the infrastructure layer 130 is called a south. It is called Bound API. Open Flow can be used as a southbound API. When Open Flow is used as a southbound API, gRPC for TLS (Transport Layer Security) communication in HTTP 2.0 may be used, just as TLS for creating a secure channel is used. By using gRPC for TLS communication, security of a device connected to the SDN may be secured.

Additionally, referring to FIG. 1, as an interface used for communication between the control layer 120 and the infrastructure layer 130, LISP, Border Gateway Protocol (BGP), Path Computation Element Communication Protocol (PCEP), and SNMP (Simple) are used. Interfaces specific to standard protocols and devices, such as Network Management Protocol, may be used.

According to one embodiment, the General Remote Procedure Call (gRPC) protocol may be used as the northbound API. The gRPC protocol is an RPC based protocol and may operate in Hyper Text Transfer Protocol (HTTP) 2.0. HTTP 2.0 can support multiplexed streams, header compression, stream prioritization, and server push. Since the gRPC protocol works in HTTP 2.0, and data is sent and received in the form of steam in HTTP 2.0, a response to a service can be transmitted regardless of the order of requests. Therefore, multiple contents can be transmitted asynchronously at the same time with only a single connection.

In addition, since the header table and the Huffman encoding scheme are used in the gRPC protocol to reduce the overhead of the header, when the application sends a plurality of requests and duplicate values exist in the request-header value, the header field contains duplicate values. Can be detected. Then, only the index value corresponding to the detected header field may be transmitted.

In addition, since the gRPC protocol uses a stream prioritization technique that solves the browser rendering delay problem and a server push technique that minimizes the number of client requests, the response speed can be improved by 50% or more on average.

As described above, the gRPC protocol operating in HTTP 2.0 may support a multiplexed stream function and a header compression function. Therefore, using the gRPC protocol, the RPC can be processed through a single connection through the Multiplexed Stream function. In addition, the problem of communication speed degradation due to Head-of-Line Blocking (HOLB) and head overhead, which is a problem of HTTP 1.1, may be solved by a multiplexed stream function and a header compression function. As a result, since the HTTP 2.0-based gRPC protocol supporting the multiplexed stream function and the header compression function is used as the northbound API, a problem in that the communication speed that occurs in HTTP 1.1 may be prevented.

In particular, in a big network in which a plurality of switches are connected, the degree of performance improvement may increase as the gRPC protocol is used as a northbound API. Therefore, the user can use the Big network more conveniently. When a local device calls a remote device's program or service by an application running on the local device, the gRPC protocol may cause the remote device's program or service to be invoked as though it invoked a program or service running on the local device. Thus, the developer of the application can conveniently develop the application without dealing with network communication problems. Thus, SDN's devices using the gRPC protocol as a northbound API can provide advantages in terms of efficiency and performance.

FIG. 2 is an exemplary diagram for describing an operation between an application 210 and a network service function 220 of a device connected to an SDN using a gRPC protocol with a northbound API according to an embodiment. The application 210 may be executed at the application layer of the device, and the network service function 220 may be executed at the control layer of the device. In addition to the network service function 220, other processes or services (eg, Dove Manager of FIG. 1, etc.) running in the control layer may communicate with the application 210 similar to that described in FIG. 2.

The gRPC protocol can be used using the Web. The gRPC protocol may utilize a serializer called a protocol buffer (PB). Plug-in and payload message structures that generate code for the application 210 and the network service function 220 may be provided by the serializer.

A local object 211 may be created in the application 210 for calling a process or service running in the network service function 220 or other control layer. The local object 211 may be a stub that implements the same method as the network service function 220. Referring to FIG. 2, the user 230 may call a service provided by the network service function 220 using the local object 211 of the application 210 of the device. In this case, parameters required to invoke the service may be passed from the local object 211 to the compiler 212 of the application 210. In the compiler 212, a Protocol Buffer Message (PB Message) and passed parameters may be combined based on the gRPC protocol. By combining the PB Message and the parameters, a gRPC request can be generated in the compiler 212.

The gRPC request may be transmitted to the network service function 220 using TLS communication supported in HTTP 2.0. The gRPC request includes API calls corresponding to the service called by the user 230 and parameters required to execute the API (that is, parameters required to call the service, parameters passed from the local object 211 to the compiler 212). It may include. The gRPC request may be delivered to the compiler 221 of the network service function 220. Compiler 221 may decode a gRPC request.

In the network service function 220, the declaration and implementation of the methods required for the service can be performed. Furthermore, by executing the gRPC server, the service corresponding to the request of the user 230 can be called. Referring to FIG. 2, the compiler 221 calls a service included in the PB compiler API 222 or an API repository in response to a request of a user 230 or a request of an application 210 extracted from a gRPC request. By executing a method corresponding to the service, a request of the user 230 or a request of the application 210 may be processed. The result of invoking the service or the result of executing the method may be transmitted to the compiler 221. The compiler 221 may generate a gRPC response based on a result of invoking a service or a result of executing a method. More specifically, the compiler 221 may encode a result of calling a service or a result of executing a method.

The gRPC response may be sent to the application 210 using TLS communication supported in HTTP 2.0. The gRPC response may be sent to the compiler 212 of the application 210. By the compiler 212, a result corresponding to the user 230 calling the service may be transmitted to the local object 211 or output to the user 230.

As a result, the application 210 can be operated by calling a method of the network service function 220, and as the relatively light communication protocol is used in the application 210, the application can be developed more efficiently.

An operation of calling a service of the network service function 220 by the application 210 described with reference to FIG. 2 may also be performed in reverse. That is, the service or method of the application 210 may be called by the network service function 220.

3 is a flowchart illustrating an operation of a device connected to an SDN using a gRPC protocol with a northbound API according to an embodiment. The device may use the gRPC protocol as an interface for exchanging information between the application layer and the control layer. The gRPC protocol can replace the Representational State Transfer (REST) API, a Northbound API based on HTTP 1.1.

Referring to FIG. 3, in step 310, the device may receive a request for calling a method or service of a control layer from an application. Conversely, a device may receive a request to invoke a method or service of an application from a process (eg, a network service function) running at the control layer. The request may be generated by a local object implemented in an application or a network service function.

Referring to FIG. 3, in step 320, the device may generate a gRPC request in response to the received request. The gRPC request may be generated by the compiler or gRPC service that received the request. When a request is received from an application, the gRPC request may be generated by a compiler or a gRPC service executed in response to the application. When a request is received from a process executed in the control layer, the gRPC request may be generated by a compiler or a gRPC service executed corresponding to the process. The gRPC request may contain parameters for the method or service targeted for the call.

Referring to FIG. 3, in step 330, the device may transmit the generated gRPC request through gRPC. The gRPC request may be sent using HTTP 2.0 based TLS communication. gRPC requests can be sent to processes in the application or control layer that target the call. The process of the application or control layer that receives the gRPC request may return the result of calling a method or service in response to the gRPC request through the gRPC response.

In step 340, when receiving a gRPC response corresponding to the gRPC request, in step 350, the device provides the results included in the gRPC response to the process of the application or control layer that sent the request in step 310. can do. When an application sends a request, the result contained in the gRPC response may include the result of invoking a method or service provided by a process in the control layer. In this case, the device can send the results contained in the gRPC response to the application. When a process in the control layer sends a request, the result contained in the gRPC response may include the result of invoking a method or service provided by the application. In this case, the device can send the results contained in the gRPC response to the control layer's process.

4 is a flowchart illustrating an operation performed by a device connected to an SDN using a gRPC protocol as a northbound API in response to a gRPC request.

Referring to FIG. 4, in step 410, the device may receive a gRPC request. The gRPC request may be received from a process at the application or control layer based on HTTP 2.0.

Referring to FIG. 4, in step 420, the device may decode the received gRPC request. The device may identify the method or service of the control layer or the application that is called by the process of the application or control layer that has sent the gRPC request by decoding the received gRPC request.

Referring to FIG. 4, at step 430, the device may execute or invoke the identified method or service. When the gRPC request generated by the application is received, the device may call a method or service included in the process of the control layer. When the gRPC request generated by the process of the control layer is received, the device may call a method or service included in the application. In the process of invoking a method or service, the device may utilize parameters included in a gRPC request.

Referring to FIG. 4, in step 440, the device may generate a gRPC response that includes a result value of the called method or service. In operation 450, the device may transmit the generated gRPC response to a process of an application or control layer that has sent a gRPC request. The gRPC response may be sent based on HTTP 2.0.

In summary, a device according to an embodiment may be a server or a terminal included in an SDN, and may transmit data transmitted between an application layer and a control layer using a gRPC protocol. More specifically, the gRPC protocol may be used as a northbound API called by the process of each of the application layer and the control layer. As the gRPC protocol that can be used in RPC-based HTTP 2.0 is used, the performance of communication speed, convenience of developer, and security can be improved. Therefore, as the security and speed between the application layer and the control layer are improved, the stability of the SDN can be improved. Furthermore, the intelligence of the network using SDN can be more easily implemented due to the convenience of application development.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). Can be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the claims that follow.

110: application layer
120: control layer
130: infrastructure layer

Claims (10)

Receiving a request to call a method from an application included in an application layer;
Transmitting the request through a gRPC to a network service function having the method among a plurality of network service functions included in a control layer controlling a network;
Receiving a result corresponding to the request from a network service function having the method; And
Providing the received result to the application
Including,
Receiving the request,
A communication method for an application layer in a software defined network (SDN) for receiving the request based on a call of a method included in a local object of the application layer. The method of claim 1,
The gRPC is,
A communication method for an application layer in an SDN used as a northbound API for communication between the control layer and the application layer. The method of claim 1,
Delivering the request,
A communication method for an application layer in the SDN for delivering a protocol buffer (PB) message combined with the parameters included in the request to the network service function. delete The method of claim 1,
Receiving the result,
The communication method for the application layer in the SDN receiving the result of calling the method of the network service function in accordance with the forwarded request. Receiving a request for calling a method from a network service function included in a control layer controlling a network;
Transmitting the request through a general remote procedure call (gRPC) to an application having the method among a plurality of applications belonging to an application layer;
Receiving, from an application having the method, a result corresponding to the request; And
Providing the received result to the network service function
Communication method for an application layer in a software defined network (SDN) comprising a. The method of claim 6,
The gRPC is,
A communication method for an application layer in SDN used as a northbound API for communication between the control layer and the application layer. The method of claim 6,
Delivering the request,
A communication method for an application layer in the SDN for delivering a combined PB message included in the request to the application. The method of claim 6,
Receiving the request,
And a communication method for an application layer in the SDN receiving the request based on a call of a method included in a local object of the control layer. The method of claim 6,
Receiving the result,
And communication method for an application layer in the SDN receiving a result of calling a method of the application according to the forwarded request.

Images