External injection of cloud network functions into network services

A plurality of embodiments relate generally to virtual network services, especially to the integration of external network functions into network services.

Cloud-based network services can enable a variety of separately provided solutions to be integrated into a virtual network in a way that is transparent to service users. For example, a cloud-based network service provided by one entity can incorporate firewall services provided by a second entity and is available to users so that third parties can make those services available. Expand services.

In general, networks integrate external services by adapting them to the application programming interface (API) of the external service. The network can modify its behavior to implement APIs, instantiate external services, and properly route traffic through these external services. However, modifying network behavior and integrating it into the API can be time consuming and labor intensive.

Considering the above, it would be advantageous to provide a mechanism for multiple external network service providers to communicate API descriptions that can be incorporated into network operations to use external services.

In one embodiment, the system receives a description of an application programming interface (API) from a service provider. The system makes API calls based on the traffic flow and creates a new instance of the service provided by the service provider. This causes the call to be as specified in the description.<u style="single">format</u>And send an API call to the service provider. The system sends the traffic flow to the service provider and receives the traffic flow. The service provider is applying the service to the traffic flow.

Methods and embodiments of computer-readable media are also disclosed.

A further plurality of embodiments and features, as well as the structures and operations of the various embodiments, are described in detail below with reference to the plurality of accompanying drawings.

Multiple attachments are incorporated herein and form part of this specification.

<figref num="1A">It is a block diagram of a networking environment for integrating a cloud-based external service into a network according to an example of an embodiment.</figref>

<figref num="1B">It is a block diagram which shows further detail of a networking environment for integrating a cloud-based external service into a network according to an example of embodiment.</figref>

<figref num="2">It is a block diagram which shows an example of the registration API call for registering a network service API function in a network according to an example of an embodiment.</figref>

<figref num="3">It is a figure which shows the series of calls for network API function registration and instantiation according to an example of embodiment.</figref>

<figref num="4">It is a flowchart explaining the process for starting an external service in a network service according to an example of embodiment.</figref>

In multiple drawings, similar reference numbers generally refer to the same or similar elements. Further, generally the leftmost number of the reference number identifies the drawing in which the reference number first appears.

Provided herein are embodiments of systems, methods, and / or computer program products, and / or combinations and partial combinations thereof, which provide API descriptions for external network services and their APIs. Is for integrating external services into the network using.

FIG. 1A shows a networking environment 100 for integrating cloud-based external services into a network according to an example of an embodiment.

The networking environment 100 includes clients 110a and 110b, network 120, and network service providers 130a-130b.

In one embodiment, clients 110a and 110b communicate via network 120. Each of the clients 110a and 110b can be any computing device or a combination of multiple computing devices, communicating over a network such as a personal computer, server, mobile device, local area network (LAN), etc. obtain. Clients 110a and 110b can be clients of network 120. In another embodiment, the clients 110a and 110b communicate via a virtual LAN (VLAN) configured by the network 120.

Network 120 includes a network of nodes 122a-f configured to route data traffic between clients, such as between clients 110a and 110b. For example, network 120 is a metropolitan area network (MAN) or wide area network (WAN). In one embodiment, network 120 provides virtual networking services such as VLANs, virtual private networks (VPNs), and the like. In one embodiment, network 120 provides Ethernet® interoperability between clients at remote locations. For example, network 120 provides virtual circuits with dedicated bandwidth for data communication between clients at remote locations. The network 120 may utilize any point-to-point, point-to-multipoint, or multipoint-to-multipoint networking protocol. Network access protocols used include, for example, Ethernet®, Asynchronous Transfer Mode (ATM), High Level Data Link Control (HDLC), Frame Relay, Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Internet Protocol ( It can include IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Multi-Protocol Label Switching (MPLS), and so on.

Network service providers 130a-130b provide network services separately from network 120. For example, provider 130a-b is hosted by a third party entity. An example of a network service is a firewall, which filters traffic flow between two communicating clients. Other examples of network services include intrusion detection systems, antivirus systems, and anti-spam filters. In one embodiment, network service provider 130a-b provides network services to multiple networks. Network service provider 130a-b is responsible for creating instances of network services and for traffic to receive services.<u style="single">format</u>It provides network services by providing APIs for doing so. The network provisions the provider's services using each provider's API.

In one embodiment, network 120 also provides network services to clients. For example, network 120 provides its own firewall service for its clients. In one embodiment, the client of network 120 may choose to use the service provided by network 120 or an external provider for additional or alternative services. In one embodiment, the client selects a service and a service provider via a client portal web page.

According to one embodiment, the network service provider 130a-b provides a description of the API to the network 120 during the registration process. In this way, the provider 130 tells the network 120 how to interact with the services of the provider 130 and how to provision the services of the provider 130. Network 120 then uses this API description to make service requests and traffic transfers through the service provider.<u style="single">format</u>To do. In this way, the network 120 provisions the services of a plurality of network service providers for each provider without the need to modify the code. In one embodiment, the provider 130a-b registers each service API of the provider by calling the registration API of the network 120 and including the provider's API description as a parameter.

FIG. 1B is a block diagram showing further details of the networking environment 100 according to an example of an embodiment.

As shown in FIG. 1B, an exemplary network node 122 includes an API registration module 124, a service call module 126, a client portal module 128, and an API database 129.

In one embodiment, the API registration module 124 receives an API registration call from the network service provider. The API registration call contains an API description of the API call for provisioning network service functionality provided by the service provider. The API registration module 124 stores the API description in the API database 129.

In one embodiment, service call module 126 generates and sends API calls to provision network services. When network 120 attempts to start an external network service from a service provider, service call module 126 queries API database 129 for the API description of the API call to start the service function.

In one embodiment, the client portal module 128 receives a command from a client on network 120 to initiate an external network service. For example, client portal module 128 may receive a command from client 110a that includes a firewall provided by firewall.com for the connection between client 110a and client 110b. In one embodiment, the client portal module 128 provides a graphical user interface for clients to provision configuration and service settings. The client portal module 128 may then transfer the instruction to the service call module 126 to start the service. Client portal module 128 may provide the client with confirmation that the external service has been properly started or that the service is not available. For example, if the API for the service is not registered in the API database 129, the client portal module 128 may notify the client that the requested service is not available.

As shown in FIG. 1B, the API issuing module 132 and the service module 134 are included in the exemplary service provider 130.

In one embodiment, the API issuing module 132 communicates a registration API call for registering a network service function with the network 120 on which the service provider 130 intends to receive a service request. In one embodiment, when a new service is provided or the API of an existing service changes, the API issuing module 132 registers the service API.

In one embodiment, the service module 134 receives an API service call from the network and initiates a network service function accordingly.

FIG. 2 shows an example of a registration API call 200 for registering the network service API function 250 in the network 120 according to an example of the embodiment. API calls between network 120 and network service provider 130 include, for example, Advanced Message Queuing Protocol (AMQP), Simple Object Access Protocol (SOAP), Representational State Transfer (REST), and Java® Message Service. Can be transmitted using (JMS).

In one embodiment, the registration API call 200 includes two parts, a registration API identifier 210 and an API description 220.

In one embodiment, the registration API identifier 210 identifies the API call 200 as a call for registering an external function on the network 120. The registration API identifier 210 can be, for example, a flag that distinguishes API call 200 from other calls received by network 120.

In one embodiment, the API description 220 specifies the format and parameters transmitted when calling the external network API function 250. In one embodiment, the API description 220 includes an external service identifier 222 and a parameter 224.

The service identifier 222 identifies the external network API function 250 that will be registered. For example, the service identifier 222 can be many or a series of characters that identify the API function 250.

Parameter 224 specifies the parameters that network 120 needs to convey when provisioning external API functionality. In one embodiment, the parameters are specified from a list of parameters associated with the traffic flow to which the external network API function 250 is applied.

For example, network 120 may implement a VLAN between clients 110a and 110b and attempt to establish a firewall for traffic through the VLAN. In one example of the embodiment, the network 120 calls the external API function 250 for the firewall and establishes the firewall service provided by the external provider 130a, as described by the corresponding API description 220. As part of the API function call, network 120 may convey parameters such as traffic flow identifiers, traffic source and destination addresses, source and destination ports, and so on.

In one embodiment, network 120 has available parameters associated with traffic flow and a list of descriptors for these parameters. In one embodiment, the provider 130a registering the API function describes the API function parameter 224 using a descriptor from the list of available parameters associated with the traffic flow of the network 120. In one embodiment, API description 220 specifies the format of an API call with parameters represented as variables in the appropriate places. When forming an API call, network 120 replaces the variable with the corresponding parameter for the desired service.

FIG. 3 shows a series of calls for network API function registration and instantiation according to an example of an embodiment.

As mentioned above, the service provider 130a registers the API functionality of the service provided. To register the API function so that the network 120 can call the function, the provider 130a submits the registration API call to the network service 120, as shown in step 302. The network 120 stores the received API description in the API registration database so that it can be referred to later when starting the external service function.

At step 304, network 120 may respond with confirmation that the registration was successful.

At step 306, network 120 initiates an external service by searching the API database for the appropriate API description for the service and sending an API call to provider 130a.

At stage 308, provider 130 sends a confirmation that the API call was successful.

At stage 310, network 120 begins sending traffic through provider 130a to perform the services provided. For example, if the firewall service is initiated via an API call, network 120 sends traffic for processing through provider 130.

If the format for the API call changes, the external service provider updates the API description, for example by running process 300 again.

FIG. 4 is a flowchart illustrating a process for initiating an external service in a network service according to an example of an embodiment.

At step 402, network 120 receives a request from the client to incorporate an external service into the traffic flow. For example, client 110a may want to add a firewall provided by firewall.com to the VLAN connection between client 110a and client 110b.

At stage 404, network 120 checks to see if the requested external service is registered. In one embodiment, network 120 seeks to look up the API registration database to find the API description that corresponds to the requested external service. If network 120 cannot find the API description for the service, network 120 does not create a service instance and sends an error message to the requesting client, as shown in step 406.

If network 120 finds an API description corresponding to the requested service in stage 404, the process moves to stage 408 and makes an API call in the format described in the API description. For example, network 120 may provide API calls to create a firewall in the format specified by firewall.com. API calls include parameters in place of the variables specified in the description. For example, the API description for creating a firewall using firewall.com can be "# fw / $ FLOW_ID / $ SRC_ADDR / $ DST_ADDR / $ SRC_PORT / $ DST_PORT". The API call to establish a firewall between the two clients would then substitute the variable for the corresponding parameter of the traffic flow. For example, "# fw / 60 / 110.20.30.1 / 110.20.42.1 / 88/89".

At stage 410, network 120 initiates the service by sending an API call to an external service and forwarding traffic in the appropriate format. In the above example, network 120 sends an API call as described above, then forwards flow 60 traffic originating from node 110.20.30.1:88 and directed to 110.20.42.1:89. It will divert this flow through the firewall.com network. [Conclusion]

The API database can be any stored type of structured memory, including persistent memory. In a plurality of examples, each database may be implemented as a relational database or file system.

Each of the blocks and modules of FIGS. 1A and 1B may be implemented in hardware, software, firmware, or any combination thereof.

Each of the blocks and modules of FIGS. 1A and 1B may be implemented on the same or different computing devices. Such computing devices may include, but are not limited to, personal computers, mobile devices such as mobile phones, workstations, embedded systems, game consoles, televisions, set-top boxes, or any other computing device. Further, a computing device may include, but is not limited to, a processor and a device having memory including non-temporary memory for executing and storing instructions. Memory can explicitly embody data and program instructions. The software may include one or more applications and an operating system. Hardware can include, but is not limited to, a processor, memory, and a graphical user interface display. Computing devices can also have multiple processors and multiple shared or separate memory components. For example, the computing device may be part or all of a clustered computing environment or server farm.

Identifiers such as "(a)", "(b)", "(i)", "(ii)" may be used for different elements or stages. These identifiers are used for clarity and do not necessarily indicate the order of elements or steps.

The present invention has been described above using a plurality of functional building blocks indicating the implementation of a plurality of specific functions and their relationships. The boundaries of these functional units have been arbitrarily defined herein for convenience of description. Alternative boundaries can be demarcated as long as multiple specific functions and their relationships are properly performed.

The above description of the plurality of specific embodiments so well reveals the general nature of the present invention by applying the in-tech knowledge of the art, without undue experimentation. Without departing from the general concept of the present invention, other people can easily modify such a plurality of specific embodiments and / or easily adapt them to various uses. Accordingly, such modifications and modifications are intended to be within and within the scope of the disclosed equivalents of the embodiments, based on the teachings and guidance provided herein. The terms or terms herein are for illustration purposes only and are not limiting, which means that the terms or terms herein will be interpreted by one of ordinary skill in the art in consideration of teaching and guidance. It should be understood that

The breadth and scope of the plurality of embodiments should not be limited by any of the plurality of examples described above, but should be defined solely on the basis of the following claims and their equivalents.