Dynamic service orchestration within PaaS platforms

According to one exemplary embodiment, a method for orchestrating a flow of a packet through a software-defined network (SDN) switch is provided. The method may include determining at least one available service associated with the SDN switch. The method may also include receiving the packet at an input port associated with the SDN switch, wherein the packet has a destination value and a packet type. The method may then include generating a flow entry based on the at least one available service and the packet type, wherein the flow entry has a plurality of entry characteristics and an action. The method may further include selecting the flow entry based on matching the plurality of entry characteristics to the destination value and the packet type. The method may also include performing the action associated with the selected flow entry.

BACKGROUND

The present invention relates generally to the field of computing, and more particularly to Platform-As-A-Service (PaaS) services.

PaaS frameworks provide the core building block for cloud applications that allow developers to focus on code creation without having to worry about how an application may be scaled at runtime. To improve cloud application development, PaaS platforms typically provide a service feature that allows developers to use the services provided by the PaaS platform in the developer's application when the PaaS platform binds the application with the service instance at runtime. Services commonly present in PaaS platforms include queuing services, database services, or email services.

SUMMARY

According to one exemplary embodiment, a method for orchestrating a flow of a packet through a software-defined network (SDN) switch is provided. The method may include determining at least one available service associated with the SDN switch. The method may also include receiving the packet at an input port associated with the SDN switch, wherein the packet has a destination value and a packet type. The method may then include generating a flow entry based on the at least one available service and the packet type, wherein the flow entry has a plurality of entry characteristics and an action. The method may further include selecting the flow entry based on matching the plurality of entry characteristics to the destination value and the packet type. The method may also include performing the action associated with the selected flow entry.

According to another exemplary embodiment, a computer system for orchestrating a flow of a packet through a software-defined network (SDN) switch is provided. The computer system may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the computer system is capable of performing a method. The method may include determining at least one available service associated with the SDN switch. The method may also include receiving the packet at an input port associated with the SDN switch, wherein the packet has a destination value and a packet type. The method may then include generating a flow entry based on the at least one available service and the packet type, wherein the flow entry has a plurality of entry characteristics and an action. The method may further include selecting the flow entry based on matching the plurality of entry characteristics to the destination value and the packet type. The method may also include performing the action associated with the selected flow entry.

According to yet another exemplary embodiment, a computer program product for orchestrating a flow of a packet through a software-defined network (SDN) switch is provided. The computer program product may include one or more computer-readable storage devices and program instructions stored on at least one of the one or more tangible storage devices, the program instructions executable by a processor. The computer program product may include program instructions to determine at least one available service associated with the SDN switch. The computer program product may also include program instructions to receive the packet at an input port associated with the SDN switch, wherein the packet has a destination value and a packet type. The computer program product may then include program instructions to generate a flow entry based on the at least one available service and the packet type, wherein the flow entry has a plurality of entry characteristics and an action. The computer program product may further include program instructions to select the flow entry based on matching the plurality of entry characteristics to the destination value and the packet type. The computer program product may also include program instructions to perform the action associated with the selected flow entry.

DETAILED DESCRIPTION

The following described exemplary embodiments provide a system, method and program product for dynamic service orchestration in PaaS platforms. As such, the present embodiment has the capacity to improve the technical field of differentiating infrastructure services from application services by providing a service chaining mechanism that makes orchestration of infrastructure services feasible while minimizing performance impact. More specifically, packet flow through software-defined network (SDN) switches to application services may be dynamically altered by a service orchestrator, whereby packets may be sent to services based on the services available and the packet type.

As previously described, most Platform-As-A-Service (PaaS) frameworks provide a way for developers to use services (e.g., database services, email services, etc.) in an application. The PaaS platform may bind the application with the service instance at runtime. Some services may provide value to the application while being transparent to the developer. Such services may be categorized as infrastructure services. Example infrastructure services may include packet inspection services, packet capture services, and traffic control services.

A packet inspection service may inspect all network traffic targeted at a specific application to identify security flaws. Example packet inspection services may include Intrusion Detection and Prevention System (IDPS), malware detection, email spam detection, etc.

Packet capture services may capture all requests targeted at a specific application for analysis and auditing. Responses from the target application may also be captured. Example packet capture services may include web application program interface (API) monitors, IBM® QRadar® (IBM, QRadar and all IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation and/or its affiliates), etc.

Traffic control services allow administrators to define Service Level Management (SLM) policies to associate with a specific application. A traffic control service may restrict the number of requests that may be routed to the specific application. Example traffic control services may include Application Performance Monitoring (APM) management, traffic shaping, etc.

PaaS platforms may not provide well-defined, scalable mechanisms to differentiate infrastructure services from application services and may not associate the services with a target application.

Therefore, it may be advantageous to, among other things, provide a way to scalably orchestrate infrastructure services within PaaS platforms while minimizing performance impacts.

According to at least one embodiment, a service chaining mechanism may be added to a PaaS platform that makes orchestration of infrastructure services feasible with minimal impacts on performance. A service orchestrator may be implemented as a Software-Defined Network (SDN) controller in the gateway of the PaaS platform. The gateway may perform infrastructure service orchestration by generating service chaining SDN flow commands based on identified service routing policies. The flow command may be sent to the SDN switch at either configuration time (when running in proactive mode) or runtime (when running in reactive mode). Infrastructure services may be dynamically registered to the gateway to allow the gateway to determine the type of services available in the infrastructure and how to perform service chaining based on layer 2 (L2) information (e.g., media access control (MAC) address). Additionally, the service routing policy defined on the gateway may support conditional branching actions that allow the packet routing to be created at runtime.

At configuration time, the gateway may subscribe to a service registration message so the gateway may know what infrastructure services may be available for use. The gateway may look up L2 information from an Infrastructure-As-A-Service (IaaS) controller based on a service name and Internet Protocol (IP) address. Using the L2 information, an administrator may create a service chaining policy outlining a list of infrastructure services that need to be executed before a request may be routed to a target application. The gateway may then turn the policy into commands (e.g., OpenFlow commands) and populate the flow table of an SDN switch. According to at least one embodiment, the flow table may have multiple rows of flow table entries that contain fields corresponding to the protocol, priority, network source address, input port, network destination address and a designated action for the SDN switch to take. The action specified in the flow entry may indicate that a response to the SDN controller may be sent, indicate an SDN switch port to send out a packet, modify a destination MAC address to send the packet, or a combination of actions.

At runtime, the gateway may perform layer 3 (L3) routing based on the request header payload and the SDN switch may perform the service chaining based on the SDN switch's flow table. Processing service chaining may be offloaded to the SDN switch level in the interest of efficiency.

Additionally, to provide more flexibility for various chaining scenarios, the policy created by the gateway may contain a conditional branch operation that may have the SDN switch hold the request flow until the gateway makes a new routing decision based on the out-of-band response from one of the previously executed services. For example, one of the services may return a negative response to the gateway which may result in the gateway inserting a new set of OpenFlow rules to the SDN switch for subsequent routing.

Referring now toFIG. 1, an exemplary networked computer environment100in accordance with one embodiment is depicted. The networked computer environment100may include a computer102with a processor104and a data storage device106that is enabled to run a service orchestration program108a. The networked computer environment100may also include a server110that is enabled to run a service orchestration program108band a communication network112. The networked computer environment100may include a plurality of computers102and servers110, only one of which is shown for illustrative brevity. The communication network may include various types of communication networks, such as a wide area network (WAN), local area network (LAN), a telecommunication network, a wireless network, a public switched network and/or a satellite network. It may be appreciated thatFIG. 1provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements.

The client computer102may communicate with server computer110via the communications network112. The communications network112may include connections, such as wire, wireless communication links, or fiber optic cables. As will be discussed with reference toFIG. 7, server computer110may include internal components902aand external components904a, respectively and client computer102may include internal components902band external components904b, respectively. Client computer102may be, for example, a mobile device, a telephone, a PDA, a netbook, a laptop computer, a tablet computer, a desktop computer, or any type of computing device capable of running a program and accessing a network.

A program, such as a service orchestration program108aand108bmay run on the client computer102or on the server computer110. The service orchestration program108aand108bmay be used to scalably orchestrate services within a PaaS platform. The service orchestration program108aand108bis explained in further detail below with respect toFIGS. 3 and 4.

Referring now toFIG. 2, a block diagram of a service orchestration architecture200according to at least one embodiment is depicted. The service orchestration architecture200may include a gateway202having a software-defined network (SDN) controller204and a service flow controller206. Additionally, the service orchestration architecture200may include a service register208, an SDN switch210, services212a-b, and an application214. The services212a-band application214may be accessed by the gateway202and service register208via the SDN switch210.

The gateway202may perform infrastructure service orchestration using the SDN controller204and service flow controller206. The SDN controller204may be an application in an SDN that manages traffic flow control to enable intelligent networking. The service flow controller206may be a controller used to generate and maintain service flow for each network transaction.

The service register208may be implemented as an application that registers and deregisters services212a-b. The SDN switch210may be used to separate the data path from the control path. The data path portion resides on the switch and a separate controller makes high-level routing decisions. Services212a-bmay be cloud-computing services (e.g., packet inspection service) that may be deployed on a PaaS platform. The application214may be a standard PaaS application used by the client216. The services212a-bmay act as proxy services to provide features for the application214such as security protection, etc. For the services212a-bto act as proxy services, the services212a-bmay need to inspect packets before the packets arrive at the application214. For example, a traffic control service (e.g.,212a) may enforce traffic threat protection system (TPS) limit policies to protect the application214from denial of service (DOS) attacks.

The services212a-b, when deployed on a PaaS platform, are registered on the service register208with information describing if the service212a-bshould run in a proactive or reactive mode. A service212a-bmay be classified as being in a proactive mode if the service's212a-bresult will not impact the flow of packet transmission (i.e., packet routing). For example, a packet capture service (e.g.,212b) may record whatever the service (e.g.,212b) received, thus the processing result of the service (e.g.,212b) will not impact the routing of the packet. In the case of a reactive service (e.g.,212a), the service's (e.g.,212a) processing of the packet may impact the flow of packet transmission. A reactive service (e.g.,212a) may generate a signal (i.e., result code) that may be sent back to the gateway202. The overall flow of packet transmission may be proactive or reactive depending on the characteristics of the services chained together. A gateway202may be running in reactive mode if any service212a-bbeing chained together in the flow of packet transmission has been identified as a reactive service. However, if there are no reactive services212a-bthat are being chained, the gateway202may run in proactive mode. The proactive mode is explained in further detail below with respect toFIG. 3and the reactive mode is explained in further detail below with respect toFIG. 4.

Referring now toFIG. 3, an operational flow chart illustrating the exemplary proactive process300by the service orchestration program108aand108b(FIG. 1) according to at least one embodiment is depicted.

At302, it may be determined if a service (e.g.,212a:FIG. 2) connected to the SDN switch210(FIG. 2) is online or offline. In response to detecting that the service (e.g.,212a:FIG. 2) is online or offline, the service register208(FIG. 2) may register the service (e.g.,212a:FIG. 2) if the service (e.g.,212a:FIG. 2) is online, or deregister the service (e.g.,212a:FIG. 2) if the service (e.g.,212a:FIG. 2) is offline at304. For example, if service212a(FIG. 2) is determined to be online, the service register208(FIG. 2) may register service212a(FIG. 2) to the SDN switch210(FIG. 2).

Next, at configuration time (i.e., pre-runtime), the service flow controller206(FIG. 2) may query the service register208(FIG. 2) for services212a-b(FIG. 2) associated with a packet type (e.g., the packet payload may indicate the packet type) of an incoming packet at306. According to at least one embodiment, the service register208(FIG. 2) may return a list of services212a-b(FIG. 2) that are registered and are designated to process the packet type of the incoming packet.

Based on the query response from the service register208(FIG. 2) at306and pre-defined configuration data (e.g., service chaining policy), the service flow controller206(FIG. 2) pre-configures service flows for the SDN switch flow table at308. According to at least one embodiment, the pre-configured service flows may be represented as flow entries for the flow table. The flow entries may contain information indicating an action to take, such as directing where to send a packet, modifying a MAC address, or some other action based on the SDN switch210(FIG. 2) port that the packet was received (i.e., input field of the flow entry) and the network destination of the packet (i.e., destination field) such as an IP address. For example, a flow entry may contain information indicating that a packet received at the SDN switch's210(FIG. 2) input port having an IP address destination to 192.168.123.101 will be sent to the SDN switch port connected to the input of inline packet inspection service212a(FIG. 2). Additionally, the service flow controller206(FIG. 2) may push one or more configured flow entries to the SDN switch210(FIG. 2) for the SDN switch210(FIG. 2) to update the SDN switch's210(FIG. 2) flow table.

At310, the gateway202(FIG. 2) may receive the incoming packet from the client216(FIG. 2). The packet may have characteristics including a destination value (e.g., destination IP address) contained in the packet header data. The gateway202(FIG. 2) may then send the packet to the SDN switch210(FIG. 2) at312. The SDN switch210(FIG. 2) may receive the packet sent by the gateway202(FIG. 2) at314. After receiving the packet, the SDN switch210(FIG. 2) may search the SDN switch's210(FIG. 2) flow table for a flow table entry (that may include the flow entries previously pushed to the SDN switch210(FIG. 2) from the service flow controller206(FIG. 2) at308) that indicates how to handle the packet type of the received packet at316. For example, the SDN switch's210(FIG. 2) flow table may be searched for a flow table entry corresponding to a packet being of a type of packet that is received at the SDN switch's210(FIG. 2) input port having an IP address destination to 192.168.123.101. If a matching flow table entry is found that matches the packet type of the incoming packet, the action to take specified in the flow table may be carried out (e.g., the packet will be sent to the SDN switch port connected to the input of inline packet inspection service212a:FIG. 2).

At318, the SDN switch210(FIG. 2) may send the packet to the service (e.g.,212a:FIG. 2) as indicated in the matching flow entry found in the SDN switch's210(FIG. 2) flow table. According to at least one embodiment, the flow entry may be configured to direct the flow of the packet out of the port attached to the SDN switch210(FIG. 2) that is connected to the service's (e.g.,212a:FIG. 2) input network interface controller (NIC).

Then, at320, the service (e.g.,212a:FIG. 2) may receive the packet from the SDN switch210(FIG. 2) and may process the packet. For example, inline service (e.g.,212a:FIG. 2) may be a packet inspection service that process the packet by inspecting the packet received from the SDN switch210(FIG. 2) for security flaws.

Next, at322, the proactive service300may determine if the service (e.g.,212a:FIG. 2) outputs to the SDN controller204(FIG. 2). According to at least one embodiment, the flow table may indicate, based on the port that the SDN switch210(FIG. 2) received the packet, that the service's (e.g.,212a:FIG. 2) output is destined for the SDN controller204(FIG. 2).

If the proactive process300determined that the service (e.g.,212a:FIG. 2) does not output to the SDN controller204(FIG. 2) at322, the proactive process300may perform the action indicated by the flow table entry at324. For example, the flow table entry may indicate that the packet should be sent out the output port of the SDN switch210(FIG. 2) and to the packet's destination IP address.

However, if the proactive process300determined that the service (e.g.,212a:FIG. 2) does output to the SDN controller204(FIG. 2) at322, the service (e.g.,212a:FIG. 2) may then send output data from the service (e.g.,212a:FIG. 2) to the SDN controller204(FIG. 2) at326. Thereafter, the SDN switch210(FIG. 2) may search the flow table for how to handle the next packet at316.

Referring now toFIG. 4, an operational flow chart illustrating the exemplary reactive process400by the service orchestration program108aand108b(FIG. 1) according to at least one embodiment is depicted.

At402, it may be determined if a service (e.g.,212a:FIG. 2) connected to the SDN switch210(FIG. 2) is online or offline. In response to detecting that the service (e.g.,212a:FIG. 2) is online or offline, the service register208(FIG. 2) may register the service (e.g.,212a:FIG. 2) if the service (e.g.,212a:FIG. 2) is online, or deregister the service (e.g.,212a:FIG. 2) if the service (e.g.,212a:FIG. 2) is offline at404. For example, if service212a(FIG. 2) is determined to be online, the service register208(FIG. 2) may register service212a(FIG. 2) to the SDN switch210(FIG. 2).

Next, the service flow controller206(FIG. 2) may query the service register208(FIG. 2) for services212a-b(FIG. 2) associated with a packet type (e.g., a packet payload may indicate the packet type) of an incoming packet at406. According to at least one embodiment, the service register208(FIG. 2) may return a list of services212a-b(FIG. 2) that are registered and are designated to process the packet type of the incoming packet.

Then, at408, the gateway202(FIG. 2) may receive the incoming packet from the client216(FIG. 2). At410, based on the query response from the service register208(FIG. 2) at406, and in some cases a result code (as will be discussed in further detail below), the service flow controller204(FIG. 2) may generate a new service flow table for the type of packet received at410by creating one or more new flow table entries. The flow entries may contain information indicating where to send a packet (or other action to take) based on the SDN switch210(FIG. 2) port that the packet was received and the network destination of the packet (e.g., IP address). For example, a flow entry may contain information indicating that a packet received at the SDN switch's210(FIG. 2) input port having an IP address destination to 192.168.123.101 will be sent to the SDN switch port connected to the input of inline packet inspection service212a(FIG. 2). Additionally, the service flow controller206(FIG. 2) may push one or more configured flow entries to the SDN switch210(FIG. 2) for the SDN switch210(FIG. 2) to update the SDN switch's210(FIG. 2) flow table.

Next, at412, the gateway202(FIG. 2) may then send the packet to the SDN switch210(FIG. 2) at412. The SDN switch210(FIG. 2) may receive the packet sent by the gateway202(FIG. 2) at414. After receiving the packet, the SDN switch210(FIG. 2) may search the flow table for a flow table entry indicating how to handle the received packet type at416.

At418, the SDN switch210(FIG. 2) may send the packet to the service (e.g.,212a:FIG. 2) as indicated in the matching flow entry found in the SDN switch's210(FIG. 2) flow table. According to at least one embodiment, the flow entry may be configured to direct the flow of the packet out of the port attached to the SDN switch210(FIG. 2) that is connected to the service's (e.g.,212a:FIG. 2) input network interface controller (NIC).

Then, at420, the service (e.g.,212a:FIG. 2) may receive the packet from the SDN switch210(FIG. 2) and may process the packet. For example, inline service (e.g.,212a:FIG. 2) may be a packet inspection service that process the packet by inspecting the packet received from the SDN switch210(FIG. 2) for security flaws.

Next, at422, the reactive service400may determine if the service (e.g.,212a:FIG. 2) outputs to the SDN controller204(FIG. 2). According to at least one embodiment, the flow table may indicate, based on the port that the SDN switch210(FIG. 2) received the packet, that the service's (e.g.,212a:FIG. 2) output is destined for the SDN controller204(FIG. 2).

If the reactive process400determined that the service (e.g.,212a:FIG. 2) does not output to the SDN controller204(FIG. 2) at422, the reactive process400may perform the action indicated by the flow table entry at424. For example, the flow table entry may indicate that the packet should be sent out the output port of the SDN switch210(FIG. 2) and to the packet's destination IP address.

However, if the reactive process400determined that the service (e.g.,212a:FIG. 2) does output to the SDN controller204(FIG. 2) at422, the service (e.g.,212a:FIG. 2) may then generate and send a result code to the gateway202(FIG. 2) after the service (e.g.,212a:FIG. 2) finishes processing the packet at426. According to at least one embodiment the result code may be generated as a result of the service's (e.g.,212a:FIG. 2) processing of the packet and may be used to subsequently alter packet flow. For example, if a service (e.g.,212a:FIG. 2) detects malicious code within the packet, a result code may be generated indicating that malicious code was detected. Then, at428, the gateway202(FIG. 2) may receive the result code the service (e.g.,212a:FIG. 2) sent at426to influence subsequent flow entry generation at410.

Next, at430, the service (e.g.,212a:FIG. 2) may return the resulting packet after packet processing done at420to the SDN switch210(FIG. 2).

Referring now toFIGS. 5A and 5B, two exemplary proactive scenarios500a-bare depicted. Both proactive scenarios500aand500bcontrol the flow of a packet based on the proactive process300(FIG. 3) described previously. The proactive scenarios500a-band proactive flow table502depict a situation with an SDN switch210having six ports504a-fand two proactive inline services212aand212b. The SDN switch210shown is a service switch that only allows network service instances to connect to the SDN switch210.

Each service212a-bhas two network interface controllers (NICs) connected to the SDN switch210ports504b-e. In both proactive scenarios500a-b, the two NICs of service212aconnect to the SDN switch210via ports504band504c. The two NICs of service212bconnect to the SDN switch210via ports504dand504e. Additionally, SDN switch210has an input port504aand output port504f.

In proactive scenario500a, the two services (i.e., service212aand service212b) are online and available for packets destined to internet protocol (IP) address 192.168.123.101. The incoming packet enters the SDN switch210via input port504adestined for IP address 192.168.123.101 from the gateway202(FIG. 2) (based on previously described step312: FIG.3). After the SDN switch210receives the packet (based on previously described step314:FIG. 3), the SDN switch210searches the proactive flow table502(based on previously described step316:FIG. 3). After searching the flow table502, the proactive process300(FIG. 3) will determine that the packet is destined for an inline service (i.e.,212a) since the first row (i.e., flow entry1) of the proactive flow table502corresponds to the situation when a packet arrives at port504adestined for IP address 192.168.123.101 and indicates that the action to be taken is to send the packet to a service (i.e.,212a).

As indicated in proactive flow table502, the SDN switch210then sends the packet out of port504bleading to inline service212a(based on previously described step318:FIG. 3). The inline service212athen receives and processes the packet (based on previously described step320:FIG. 3). The proactive process300(FIG. 3) may then determine if service212aoutputs to the SDN controller204(FIG. 2) (based on previously described step322:FIG. 3). Since the proactive flow table502does not indicate that the service212aoutputs to the SDN controller204(FIG. 2), the proactive process300(FIG. 3) will perform the action indicated in the next applicable flow entry for the packet in the proactive flow table502.

Thereafter, the packet is sent out the service's212aNIC and back in to the SDN switch210through port504c. The SDN switch210then performs the next action indicated in the applicable flow chart entry (i.e., flow entry2) for handling a packet that enters port504cand is destined for IP address 192.168.123.101 (based on previously described step324:FIG. 3). The proactive flow table502indicates at row two (i.e., flow entry2) that the SDN switch210will send the packet out of port504d. The SDN switch210then sends the packet out port504dto the input NIC of inline service212bconnected to port504d(based on previously described step318:FIG. 3).

Service212bwill receive and process the packet (based on previously described step320:FIG. 3). Next, the proactive process300(FIG. 3) may determine if service212boutputs to the SDN controller204(FIG. 2) (based on previously described step322:FIG. 3). Since the proactive flow table502does not indicate that the service212boutputs to the SDN controller204(FIG. 2), the proactive process300(FIG. 3) will perform the action indicated in the next applicable flow entry for the packet in the proactive flow table502.

Thereafter, the packet is sent out the service's212bNIC and back in to the SDN switch210through port504e. The SDN switch210then performs the next action indicated in the applicable flow chart entry (i.e., flow entry3) for handling a packet that enters port504eand destined for IP address 192.168.123.101 (based on previously described step324:FIG. 3). The proactive flow table502indicates at row three (i.e., flow entry3) that the SDN switch210will send the packet out of port504f. The SDN switch210then sends the packet out the output port504fto IP address 192.168.123.101 based on the action specified in the flow table.

In proactive scenario500b, one inline service212bis online (i.e., inline service212ais not online) and available for packets destined for IP address 192.168.123.102. In proactive scenario500b, an incoming packet enters the SDN switch210via input port504adestined for IP address 192.168.123.102 from the gateway202(FIG. 2) (based on previously described step312:FIG. 3). After the SDN switch210receives the packet (based on previously described step314:FIG. 3), the SDN switch210searches the proactive flow table502(based on previously described step316:FIG. 3). After finding the correct proactive flow table502entry, the proactive process300(FIG. 3) will determine that the packet is destined for an inline service (i.e.,212b) since the fourth row (i.e., flow entry4) of the proactive flow table502corresponds to the situation when a packet arrives at port504adestined for IP address 192.168.123.102.

As indicated in flow entry4of the proactive flow table502, the SDN switch210sends the packet out of port504dleading to inline service212b(based on previously described step318:FIG. 3). The inline service212bthen receives and processes the packet (based on previously described step320:FIG. 3). Next, the proactive process300(FIG. 3) may determine if service212boutputs to the SDN controller204(FIG. 2) (based on previously described step322:FIG. 3). Since the proactive flow table502does not indicate that the service212boutputs to the SDN controller204(FIG. 2), the proactive process300(FIG. 3) will perform the action indicated in the next applicable flow entry for the packet in the proactive flow table502.

Thereafter, the packet is sent out the service's212bNIC and back in to the SDN switch210through port504e. The SDN switch210then performs the next action indicated in the applicable flow chart entry (i.e., flow entry5) for handling a packet that enters port504eand destined for IP address 192.168.123.102 (based on previously described step324:FIG. 3). The proactive flow table502indicates at row five (i.e., flow entry5) that the SDN switch210will send the packet out of port504f. The SDN switch210then sends the packet out the output port504fto IP address 192.168.123.102 based on the action specified in the flow table.

Referring now toFIGS. 6A and 6B, an exemplary reactive scenario600is depicted. The reactive scenario600illustrates packet flow control based on the reactive process400(FIG. 4) described previously for packets having a destination IP address of 192.168.123.103.

The reactive scenario600and reactive flow table602illustrate a scenario with an SDN switch210having six ports504a-f, two inline services212c-d, and a gateway202. The SDN switch210shown is a service switch that only allows network service instances to connect to the SDN switch210. The gateway202includes the service flow controller206and SDN controller204.

Each service212c-dhas a two network interface controllers (NICs) connected to the SDN switch210ports504a-f. In reactive scenario600, the two NICs of service212cconnect to the SDN switch210(i.e., via ports504band504c) and the two NICs of service212dconnect to the SDN switch210(i.e., via ports504dand504e). Additionally, the SDN switch210has an input port504aand output port504f. The gateway202connects to the SDN switch210via the input port504a.

The reactive flow table602, is generated according to reactive process400(FIG. 4) (based on previously described step410:FIG. 4), initially only including the first row (i.e., flow entry1) and second row (i.e., flow entry2) with subsequent rows being generated on a reactionary basis by the reactive process400(FIG. 4). When the services212c-dare initially registered by the service register208(FIG. 2), they are identified as being in either reactive mode or proactive mode (based on previously described step404:FIG. 4). In the reactive scenario600, service212cis identified as being in reactive mode and service212dis identified as being in proactive mode. Since at least one service (i.e.,212c) is operating in reactive mode, the reactive process400(FIG. 4) is used to control the flow of the packet.

In reactive scenario600, the two services (i.e., service212cand service212d) are online and available for packets destined to internet protocol (IP) address 192.168.123.103. The incoming packet is transmitted from the gateway202to the SDN switch210via input port504adestined for IP address 192.168.123.103 (based on previously described step412:FIG. 4). After the SDN switch210receives the packet (based on previously described step414:FIG. 4), the SDN switch210searches the reactive flow table602for an applicable flow entry (based on previously described step416:FIG. 4). After finding the correct flow table entry, the reactive process400(FIG. 4) will determine what inline service (e.g.,212c) the packet is destined for (based on previously described step418:FIG. 4). Since the first row (i.e., flow entry1) of the reactive flow table602corresponds to the situation when a packet arrives at port504adestined for IP address 192.168.123.103, the SDN switch210will send the packet out of port504bleading to inline service212c(based on previously described step418:FIG. 4). Then, service212creceives and processes the packet (based on previously described step420:FIG. 4).

Next, the SDN switch210will determine if the service (i.e.,212c) outputs to the SDN controller204by searching the reactive flow table602for a flow entry indicating where the service's212coutput will be sent. The reactive flow table602at flow entry2indicates that service212coutput is sent TO_CONTROLLER (i.e., sent to the SDN controller204). Thus, the reactive process400(FIG. 4) will determine that the service212cdoes output to the SDN controller204(based on previously described step422:FIG. 4). The service212cwill then send a result code to the SDN controller204located in the gateway202(based on previously described step426:FIG. 4). After the SDN controller204receives the result code (based on previously described step428:FIG. 4), the SDN controller204will parse the result code signal and determine where the remaining packets should be routed (based on previously described step410:FIG. 4). The SDN controller204within the gateway202will then push new flow entries (i.e., flow entry3and4) to the SDN switch's210reactive flow table602(based on previously described step410:FIG. 4).

Next, the SDN switch210will search the reactive flow table602for the correct flow entry to handle the next packet (based on previously described step416:FIG. 4). Flow entry3will be selected by the reactive process400(FIG. 4) for sending the next packet based on the source (i.e., nw_src) being IP address 192.168.1.1, the port504a-fthat the packet was received (i.e., in_port) being input port504aand the packet destination being IP address 192.168.123.103. As indicated in flow entry3, the packet received at port504awill be routed to proactive service212dvia port504d(i.e., actions=Output:504d) (based on previously described step418:FIG. 4). Thereafter, proactive service212dreceives and processes the packet (based on previously described step420:FIG. 4). Once the proactive service212dfinishes processing the packet, the SDN switch210will search the reactive flow table602for the next relevant flow entry. The SDN switch210will select flow entry4which corresponds to the packet being received at port504efrom IP address 192.168.1.1 destined for IP address 192.168.123.103. The reactive process400(FIG. 4) will determine (based on previously described step422:FIG. 4) that the proactive service212ddoes not output to the controller and therefore the reactive process400(FIG. 4) will perform the action specified in the selected flow entry (i.e., flow entry4) (based on previously described step424:FIG. 4). Flow entry4specifies that the packet will be sent out the SDN switch's210output port504f(i.e., actions=Output:504f) to IP address 192.168.123.103.

It may be appreciated thatFIGS. 2, 3, 4, 5A, 5B, 6A, and 6Bprovide only an illustration of a few embodiments and does not imply any limitations with regard to how different embodiments may be implemented. Many modifications to the depicted embodiment(s) may be made based on design and implementation requirements.

FIG. 7is a block diagram900of internal and external components of computers depicted inFIG. 1in accordance with an illustrative embodiment of the present invention. It should be appreciated thatFIG. 7provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements.

User client computer102(FIG. 1), and network server110(FIG. 1) may include respective sets of internal components902a, band external components904a, billustrated inFIG. 7. Each of the sets of internal components902a, bincludes one or more processors906, one or more computer-readable RAMs908and one or more computer-readable ROMs910on one or more buses912, and one or more operating systems914and one or more computer-readable tangible storage devices916. The one or more operating systems914and programs such as a service orchestration program108aand108b(FIG. 1), may be stored on one or more computer-readable tangible storage devices916for execution by one or more processors906via one or more RAMs908(which typically include cache memory). In the embodiment illustrated inFIG. 7, each of the computer-readable tangible storage devices916is a magnetic disk storage device of an internal hard drive. Alternatively, each of the computer-readable tangible storage devices916is a semiconductor storage device such as ROM910, EPROM, flash memory or any other computer-readable tangible storage device that can store a computer program and digital information.

Each set of internal components902a, balso includes a R/W drive or interface918to read from and write to one or more portable computer-readable tangible storage devices920such as a CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk or semiconductor storage device. The service orchestration program108aand108b(FIG. 1) can be stored on one or more of the respective portable computer-readable tangible storage devices920, read via the respective R/W drive or interface918and loaded into the respective hard drive916.

Each set of internal components902a, bmay also include network adapters (or switch port cards) or interfaces922such as a TCP/IP adapter cards, wireless wi-fi interface cards, or 3G or 4G wireless interface cards or other wired or wireless communication links. The service orchestration program108a(FIG. 1) in client computer102(FIG. 1) and the service orchestration program108b(FIG. 1) in network server computer110(FIG. 1) can be downloaded from an external computer (e.g., server) via a network (for example, the Internet, a local area network or other, wide area network) and respective network adapters or interfaces922. From the network adapters (or switch port adaptors) or interfaces922, the service orchestration program108a(FIG. 1) in client computer102(FIG. 1) and the service orchestration program108b(FIG. 1) in network server computer110(FIG. 1) are loaded into the respective hard drive916. The network may comprise copper wires, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Hardware and software layer1102includes hardware and software components. Examples of hardware components include: mainframes; RISC (Reduced Instruction Set Computer) architecture based servers; storage devices; networks and networking components. In some embodiments, software components include network application server software.

Virtualization layer1104provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.