WO2017080611A1

WO2017080611A1 - Software defined network system for port failure detection

Info

Publication number: WO2017080611A1
Application number: PCT/EP2015/076517
Authority: WO
Inventors: Gal SAGIE; Eran Gampel
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-11-13
Filing date: 2015-11-13
Publication date: 2017-05-18
Anticipated expiration: 2018-05-13
Also published as: CN108353027A; CN108353027B

Abstract

The present invention relates to a software defined network system 100 that comprises a first network node 101 that comprises at least one virtual communication port 102. The system 100 further comprises a second network node 103 that comprises at least another virtual communication port 104, wherein the first network node 101 and the second network node 103 are configured to exchange data over their virtual communication ports 102, 104. The system 100 further comprises a flow control entity 105 that is locally arranged between the first network node 101 and the second network node 103, wherein the flow control entity 105 is configured to generate a matching flow 106 used for virtual port failure detection.

Description

SOFTWARE DEFINED NETWORK SYSTEM FOR PORT FAILURE

DETECTION

TECHNICAL FIELD The present invention relates to a software defined network (SDN) system, a method for detecting a virtual port failure in a SDN system and a computer program product for implementing said method when carried out on a computing device. In particular, the present invention suggests a locally implemented mechanism to detect failures on virtual ports in a SDN, preferably when traffic pattern change in a virtual port or the traffic stops completely.

BACKGROUND

SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). Such a network topology simplifies networking. SDN requires some method for the control plane to communicate with the data plane. One such mechanism is called OpenFlow which is often misunderstood to be equivalent to SDN, but other mechanisms could also fit into the concept.

SDN is thus an architecture purporting to be directly programmable, agile, dynamic, manageable, cost-effective, and adaptable, seeking to be suitable for the high-bandwidth, dynamic nature of today's applications. SDN architectures decouple network control and forwarding functions, enabling network control to become directly programmable and the underlying infrastructure to be abstracted from applications and network services.

The SDN architecture is inter alia programmatically configured meaning that the SDN lets network instances configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs. The SDN architecture is inter alia centrally managed, meaning that network intelligence is centralized in software-based SDN controlling elements, such as a forwarding element, that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch. In computer networking there exist needs to failure detection services on virtual communication ports, usually when traffic patterns change in the virtual port or the traffic stops completely which might be interpreted as the application is down and/or non- responsive. The failure detection should deliver notifications each time a process is suspected to have failed (S-transition). Failure detection affects cluster and network management, application deployment and distributed computing.

There exist a few implementations for a failure detection service, yet none of those implementations have gained wide acceptance. Existing local solutions have generally been ad-hoc implementations, with little regard for standardized interfaces or interactions with other services and standards in a global system. Many issues can prevent a distributed service from gaining acceptance, but providing no standard interface and no provision for interactions with existing services and infrastructure is certainly a factor.

To detect such port failures, so called failure detection software agents in hypervisor elements are often used. The concept of a software agent provides a convenient and powerful way to describe a complex software entity that is capable of acting with a certain degree of autonomy in order to accomplish tasks on behalf of its host. Software agents try to understand how to poll the health of an application or how to poll a specific port status of the application. Thus, a software agent needs to poll every specific application on a port in the SDN which in turn is not generic and difficult to administrate. The agents require proprietary protocols and produce a massive overhead in the SDN. Those agents do not have a global overview of the SDN. A failure detection service on a virtual port of a SDN is impossible using agents.

Another known architecture to provide a port failure detection service is based on the Simple Network Management Protocol (SNMP). The SNMP allows interoperation with network nodes and other management services, it uses an existing standard which increases the prospect of wide adoption and it uses a standard designed for monitoring which allows the use of existing tools and thus enables a high quality of failure detection service. The SNMP-based failure detection usually installs counters to observe the data traffic in the SDN. SNMP is sometimes considered as an unsecure protocol and thus it is usually deactivated in a SDN, thus no SNMP functionality is obtained in a SDN. SNMP is not supported in virtual switches. SNMP uses polling mechanisms which lead to large latencies and is thus inconvenient. Yet another failure detection service is obtained by using OpenFlow and so called Flow Exports, see for instance the HyperFlow mechanism as described in Tootoonchian, A., & Ganjali, Y. "HyperFlow: A distributed control plane for OpenFlow", in Proceedings of the 2010 internet network management conference on Research on enterprise networking pp. 3-3, USENIX Association. Such Flow Exports produce massive overheads of data and thus uses expensive processing resources. Those Flow Exports have a lower granularity of failure detection. They are hard to scale and maintain with good latency.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to improve the state of the art, particularly the failure detection services as described above. The present invention has the object to decentralize the failure detection and to improve the efficiency and speed of the failure detection service. It should be possible to adapt the failure detection service to a specific local traffic pattern and network node in order to further improve the failure detection service. Thereby, the present invention seeks to avoid producing a massive overhead. A non-intrusive approach is required. Accordingly, the present invention intends to increase the overall system performance, and to decrease system latencies. The present invention also intends to overcome all the above-mentioned disadvantages.

The object of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

In particular, the present invention leverages a local failure detection, preferably on a virtual port of a network node, to understand that a certain virtual port is not responsive or not loaded. An inventive local flow control entity performs learning analytics at a first phase to learn the traffic characteristics in order to determine the best granularity. Granularity herein is related to parallel computing and means the amount of computation in relation to communication, i.e., the ratio of computation to the amount of communication. Then, any abnormal behavior, meaning data traffic which is not passing to and/or from a network node, is somehow triggered.

A first aspect of the present invention provides a SDN system that comprises a first network node that comprises at least one virtual communication port. The inventive system further comprises a second network node that comprises at least another virtual communication port, wherein the first network node and the second network node are configured to exchange data over their virtual communication ports. The inventive system additionally comprises a flow control entity that is locally arranged between the first network node and the second network node, wherein the flow control entity is configured to generate a matching flow used for virtual port failure detection.

In the system of the first aspect, a novel local flow control entity is introduced. This entity is locally arranged between a first network node and a second network node in the system. The entity is preferably a virtual entity in the SDN. The entity can be provided as an SDN application on top of a SDN controller.

The flow control entity leverages the control over the first network node and the second network node in a local manner. For that matter the inventive flow control entity can be configured either manually or automatically depending on how the SDN setup is built and which SDN controller is used. As a consequence, the speed and efficiency of the at least one data exchange between the first node and the second node is not negatively influenced and particularly the service of a port failure detection is greatly improved.

A network node might either be a connection point, a redistribution point, or a communication endpoint of terminal equipment. In data communications, a network node might either be a data communication equipment (DCE) such as a modem, hub, bridge or switch; or a data terminal equipment (DTE) such as a digital telephone handset, a printer or a host computer, for example a router, a workstation or a server. The definition of a network node depends on the network and protocol layer referred to. The network node might preferably be an active electronic device that is attached to the system and is capable of creating, receiving, or transmitting information over a physical, logical and or virtual communication channel. A passive distribution point such as a distribution frame or patch panel is consequently not a network node according to the invention. Preferably, the network node is either a virtual switch, such as a virtual multilayer network switch, designed to enable effective network automation through programmatic extensions, while supporting standard management interfaces and protocols such as NetFlow, sFlow, SPAN, RSPAN, CLI, LACP 802. lag, OpenFlow or a virtual machine, which is an emulation of a particular computer system that operates based on the computer architecture and functions of a real or hypothetical computer, and their implementations may involve specialized hardware, software, or a combination of both.

A matching flow according to the invention is a data entry generated by the flow control entity, and injected in at least one network node to observe a (virtual) communication ports behavior. This data entry preferably comprises a virtual communication port number and/or the network address. This matching flow is used to detect a complete loss of traffic and thus detects a ports failure. Using this matching flow, it is possible to detect a data traffic loss between a virtual port of the first network node and another virtual port of the second network node, preferably based on idle-timeout values. The flow control entity has full overlay topology view. Thus it has visibility on the packet path and can query the data traffic along the path in a local fashion. The flow control entity can be used to detect virtual port failures and load conditions. It is commonly supported in virtual switches and it is easy integrated with a SDN controller. The flow control entity is used to install flows without further actions. It can perform analytics and learning scenarios in order to adapt flow control entity parameters. Thus analytics on traffic patterns and application ports can be obtained in an easy manner and the best granularity for a failure detection mechanism is obtained, since it spots problems closest to the virtual communication port of the network node.

Port failure detection is preferably responsible for detection of any network node failure or crashes in the SDN. The failure detection delivers a notification each time a connection is suspected to have failed (S-transition) or is trusted again not to have failed (T- transition). Optionally, attached to these notifications is some information about the level of suspicion. In the SDN failures on virtual ports are detected, usually when traffic patterns change in a virtual port or stop completely - this means that the application in the network node is down or non-responsive.

A communication port in the SDN preferably serves as an endpoint in an operating system for many types of communication. It is preferably a virtual construct that identifies a service or process. Each network node might comprise a plurality of virtual communication ports in order to communicate with either different network nodes or the same network node over different applications.

In a first implementation form of the system according to the first aspect, the system is a virtual overlay system in a system that further comprises a physical system topology and software infrastructure with a logical system topology.

The virtual overlay network is a computer network that is built on top of another network. The network nodes in the virtual overlay network can be thought of as being connected by virtual links or logical links, each of which corresponds to a path, for instance through many physical links, in the underlying (physical and/or logical) network. For example, distributed systems such as peer-to-peer networks and client- server applications are virtual overlay networks. Thus, the functionality of the system is highly increased and the connectivity can be secured using logical and virtual entities.

In SDN a network might be separated into three different layers, an application plane, a control plane and a data plane. The application plane might comprise SDN application that explicitly, directly, and programmatically communicate its network requirements and desired network behavior to the SDN control plane, namely a SDN controller. The SDN controller is a logically centralized entity in charge of (i) translating the requirements from the SDN application down to a SDN data plane and (ii) providing the SDN application with an abstract/virtual overlay view of the network, the SDN control plane. The SDN controller is decoupled from the SDN data plane. The SDN data plane, e.g. the data paths, is a logical network topology and is controlled by the SDN controller. The logical representation might encompass all or a subset of the physical resources and so, the SDN data plane is the logical network device that forwards the actual data traffic on the physical system topology.

An OpenFlow protocol might be used to communicate between the SDN control plane standardizing the way network nodes can be programmed and configured. OpenFlow controls the traffic flow of multiple switches from a controller and acts as an interface between the controller and the physical or virtual network elements in a centralized manner. Thus, a SDN controller, such as a forwarding element, for traffic and networking management is already implemented in the inventive SDN. In a second implementation form of the system according to the first aspect as such or according to the first implementation form of the first aspect, the generated matching flow of the local flow control entity is injected as a flow entry in a forwarding element of the system. The SDN controller, such as the forwarding element, is preferably a centralized entity in an OpenFlow compliant network system. OpenFlow is a communications protocol that gives access to a forwarding plane of a network switch or router over the network. OpenFlow enables a SDN controller to determine the path of network packets through a network system of switches. In a third implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the generated matching flow of the local flow control entity comprises a destination address of the first network node or the second network node and further comprises a connection-test-packet.

Each network node in the SDN has a physical, a logical and/or a virtual address, typically one for each communication port it possesses.

Such an address might for instance be a Media Access Control address (MAC address) which is a unique identifier assigned to network ports for communications on the physical network segment. MAC addresses are used as a network address for most IEEE 802 network technologies, including Ethernet and WiFi. Logically, MAC addresses are used in the MAC protocol sub-layer of the OSI reference model.

Such an address might alternatively be an Internet Protocol address (IP address), which is a numerical label assigned to each network node participating in the SDN that uses the Internet Protocol for communication. An IP address serves two principal functions: host or network interface identification and location addressing. The flow control entity is used to detect a possible fault scenario based on the destination address in case, no traffic is determined for the observed virtual communication port.

The flow control entity is able to inject the traffic in various points along the path between the first network node and the second network node and handles the connection- test-packet arrival on the appropriate destination side by an SDN application. In a fourth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the flow control entity is locally arranged on the first node side to detect a virtual port failure of the first node or the second node. Such an implementation is useful to detect a port failure on the side of the first node in the path between the first node and the second node. The failure detection is ingress or egress or both. In some cases it might be advantageous to observe the traffic from the first node, for instance in case the first node is the preferred traffic generator and most likely the port failure occurs here.

Alternatively or additionally, the flow control entity is locally arranged on the second node side to detect a virtual port failure of the first node or the second node. Such an implementation is useful to detect a port failure on the side of the second node in the path between the first node and the second node. The failure detection is ingress or egress or both. In some cases it might be advantageous to observe the traffic from the second node, for instance in case the second node is the preferred traffic obtainer and most likely the port failure occurs here.

Alternatively or additionally, the flow control entity is locally arranged in a virtual element between the first node and the second node to detect a virtual port failure of the first node or the second node. Such an implementation is useful to detect a port failure on that occurs due to path problems. The failure detection is ingress or egress or both. In some cases it might be advantageous to observe the traffic on the path between the first node and the second node, for instance in case the virtual element is the preferred traffic distributer and most likely the port failure occurs here.

In a fifth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the generated matching flow of the local flow control entity comprises a default idle timeout value and upon expiration of the idle timeout value a virtual port failure is detected.

The idle timeout is a network parameter related to an enforced event designed to occur at the conclusion of a predetermined elapsed time. A timing element is started for the observation of data traffic pattern. In case a timer value is equal to or higher than the default timeout value, the local flow control entity assumes that the data traffic between the first node and the second node is lost. Thus, the failure detection is based on strict timing rules and the flow control entity generates a notification message upon port failure detection.

The default timeout- value can be set statically by a user of the system. In case a learning procedure occurs, the flow control entity polls the matching flow and identifies the minimum time of the data traffic propagating from the first node to the second node. The minimum timeout is identified by learning the common traffic patterns and learning the peaks of an idle timeout. Upon detection of the minimum idle timeout the failure detection can be applied to the matching flow in a second phase of the failure detection service. In a sixth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the default idle timeout value is adjusted by the local flow control entity according to specific data pattern of the system.

Thus, when the match flow expires, the flow control entity adjusts the timeout value and performs a learning procedure, including learning the behavior of the application ports and traffic pattern. The flow control entity thus learns the traffic patterns and can detect failures depending on each specific scenario between the specific network nodes. Thus it is possible to detect a failure in case a network node sends data traffic from its virtual communication port due to a load situation or an exception. It is possible to detect a non- responsive application or to detect that no traffic comes in, e.g. because the network node is shut off.

Thus, several ways to detect failure on a virtual port are described, e.g. it can be detected whether no traffic at all occurs or it can be detected, whether certain applications - e.g. based on the OSTlayer - in the network node lose their traffic. In a seventh implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the generated matching flow of the local flow control entity is configured to measure a data exchange latency time value between the first node and the second node. Thus, the traffic pattern between the first node and the second node can be identified. Thus, a learning period for the flow control entity is provided prior the actual failure detection service. In this learning period the flow control entity keeps polling the matching flow and identifies the minimum timeout value so it can detect failures by learning the common traffic patterns and identifying peaks of idle timeout.

In an eighth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the generated matching flow of the local flow control entity is used to detect a traffic loss or is used to inject connection-test-packets between the first node and the second node at a specific layer in the open system interconnection (OSI) model.

A connection-test-packet is a data packet that is configured by the flow control entity of the SDN. It is configured based on the OSI-layer in which a port behavior should be observed.

Preferably, the connection-test packet is an Address Resolution Protocol (ARP) packet. ARP is a telecommunication protocol used for resolution of network layer addresses into link layer addresses, a critical function in multiple-access networks. The ARP-packet is used to detect connectivity on an OSI-layer-2 between the first node and the second node. In case no response to the ARP is obtained by the flow control entity, it can be assumed that there is no traffic at all between the first node and the second node, e.g. because one of the nodes is shut-off or busy or in failure mode.

Preferably, the connection-test packet is a ping-packet. Ping is a computer network administration software utility used to test the reachability of a network node in the SDN and to measure the round-trip time for messages sent from the originating node to a destination node and back. The ping-packet is used to detect connectivity on an OST layer-3 between the first node and the second node.

Preferably, the connection-test packet is a Hypertext Transfer Protocol (HTTP) packet. The HTTP packet is an application protocol for distributed, collaborative, hypermedia information systems. The HTTP-packet is preferably a HTTP-Request-packet. The flow control entity checks a response to the HTTP-request based on a HTTP-check-response packet. The HTTP-packet is used to detect connectivity on an OSI-layer-4 between the first node and the second node.

Preferably, the connection-test-packet comprises several connection-test-packets of different OSI-layers to detect the port behavior and its connectivity on different OSI- layers. Thus, it is identified whether the port failure occurs on a specific OSI-layer only and on what specific OSI-layer the port failure occurs or whether the observed application is responding on each of the observed OSI-layers.

The flow control entity is used to inject the traffic in various points along the path and to handle the packet arrive on the other side by a SDN application. Thus it can pin a point, where traffic has been lost and can test various traffic types and patterns.

In a failure case, the observed service itself, or the application do not send data traffic due to various reasons. This is detected by the failure detection service as described. Since the network node could still send management data or other data traffic via another application, it is important to observe the complete network port situation. This would be possible via a low-layer connection-test-packet, such as a ping or an ARP in the match flow according to the invention.

In a ninth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the local flow control entity is configured to correlate the physical system topology and the software infrastructure with the logical system topology.

Thus, a failure, caused by a physical entity or a logical entity of the system that is detected in the virtual system using the failure detection scheme as described above, is investigated. In case the failure can only occur due to a physical or logical problem, the flow control entity notifies respectively. In a tenth form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the local flow control entity is configured to detect a misconfiguration of the system.

Preferably, a misconfiguration is an inappropriate network parameter that avoids a certain service to be applied properly. E.g. configuration identification consists of setting and maintaining baselines, which define the SDN or subsystem architecture, components, and any developments at any point in time. It is the basis by which changes to any part of a system are identified, documented, and later tracked through design, development, testing, and final delivery. It further includes the evaluation of change requests and change proposals, and their subsequent approval or disapproval. It is the process of controlling modifications to the system's design, hardware, firmware, software, and documentation. It further includes the process of recording and reporting configuration item descriptions. In case of suspected problems, the verification of baseline configuration and approved modifications can be quickly determined. It further includes an independent review of hardware and software for the purpose of assessing compliance with established performance requirements, appropriate standards, and functional, allocated, and product baselines.

In an eleventh implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, the local flow control entity is configured to inject object access method (OAM) related traffic in the matching flow. OAM is an access method which is designed for the storage of large numbers of large files, such as images. Such large files might cause problems in that the default idle timeout might elapse before those data are transferred or might block network ressources in an unexpected manner. Having the matching flow injected with such an OAM it is now possible to handle the packet arrival on the appropriate other network node by the SDN application.

A second aspect of the present invention provides a method for detecting a virtual port failure in a software defined network system. The method comprises the steps of generating a matching flow by a local flow control entity that is arranged between a first network node and a second network node in the system; injecting the generated matching flow in a forwarding element of the system; establishing the matching flow between the first node and the second node, wherein the matching flow comprises a connection-test- packet using a default idle timeout value; and detecting a virtual port failure upon expiration of the timeout value.

In a first implementation form of the method according to the second aspect, the method further comprises the step of reporting a successful receipt of the connection-test-packet in case the timeout value is not expired upon receiving of the connection-test-packet.

In a second implementation form of the method according to the second aspect as such or according to the first implementation form of the second aspect, the system is a virtual overlay system in a system that further comprises physical system topology and software infrastructure with logical system topology. In a third implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the flow control entity is locally arranged on the first node side to detect a virtual port failure of the first node or the second node; and/or the flow control entity is locally arranged on the second node side to detect a virtual port failure of the first node or the second node; and/or the flow control entity is locally arranged in a virtual element between the first node and the second node to detect a virtual port failure of the first node or the second node.

In a fourth implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the virtual port failure is detected upon expiration of the idle timeout value.

In a fifth implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the default idle timeout value is adjusted by the local flow control entity according to specific data pattern of the system. In a sixth implementation form of the method according to any of the previous implementation forms of the second aspect, the generated matching flow of the local flow control entity is configured to measure a data exchange latency time value between the first node and the second node.

In a seventh implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the generated matching flow of the local flow control entity is used to detect a traffic loss or is used to inject connection-test-packets between the first node and the second node at a specific layer in the open system interconnection model.

In an eighth implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the local flow control entity is configured to correlate the physical system topology and the software infrastructure with the logical system topology.

In a ninth implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the local flow control entity is configured to inject object access method related traffic in the matching flow. In a tenth implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, the local flow control entity is configured to detect a misconfiguration of the system.

The method of the second aspect achieves all advantages described above for the system of the first aspect.

A third aspect of the present invention provides a computer program product for implementing, when carried out on a computing device, a method for detecting a virtual port failure according to the second aspect and any of its implementation forms.

By implementing the method via the computer program product, all its advantages can be achieved.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be full formed by eternal entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

Fig. 1 shows a basic system according to an embodiment of the present invention.

Fig. 2 shows a system according to a first specific embodiment of the present invention. Fig. 3 shows a system according to a second specific embodiment of the present invention.

Fig. 4 shows a system according to a third specific embodiment of the present invention,

Fig. 5 shows a system according to a fourth specific embodiment of the present invention.

Fig. 6 shows a flow chart of a method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS Fig. 1 shows a basic system 100 according to an embodiment of the present invention. The system 100 is SDN system 100 and comprises a first network node 101 that comprises at least one virtual communication port 102. The first network node 101 may either be a DCE such as a modem, hub, bridge or switch; or a DTE such as a digital telephone handset, a printer or a host computer, for example a router, a workstation or a server.

The SDN system 100 additionally comprises a second network node 103 that comprises at least another virtual communication port 104. The second network node 103 may either be a DCE such as a modem, hub, bridge or switch; or a DTE such as a digital telephone handset, a printer or a host computer, for example a router, a workstation or a server.

The first network node 101 and the second network node 103 are configured to exchange data over their virtual communication ports 102, 104. The virtual communication port 102, 104 is a dedicated network connection for each network node in the SDN 100. It gives network nodes 101, 103 and applications on the network node 101, 103 all necessary performance, reliability and security that could be expect from a physical communication port, but add the flexibility of virtualization. Unlike physical ports, the virtual communication ports 102, 104 are customized to each network nodes 101, 103 requirements. Bandwidth can be allocated among network nodes 101, 103 at will, as can security and quality-of-service (QoS) parameters. Each network node 101, 103 gets exactly the resources it needs. The first network node 101 and the second network node 103 might be virtual switches (VS) in the SDN 100.

The virtual communication port 102, 104 gives the SDN a powerful way to control network nodes behaviour with no proprietary network node extensions or agents. Because the SDN 100 controls which physical access point, network nodes 101, 103 are connected to and allocates resources between the virtual communication ports 102, 104 it actually requires less network node intelligence. Instead of expecting network nodes 101, 103 to adapt to suit the SDN 100, the virtual port 102, 104 adapts to suit each network node 101, 103. Each virtual communication port 102, 104 offers an extra line of security. Each node 101, 103 is confined within its own virtual network, with access rights set to match the node's capability and a user's role. Per-user firewalls also let access rights be customized, protecting the SDN from privilege escalation and insider threats.

The SDN system 100 further comprises a flow control entity 105 that is arranged locally between the first node 101 and the second node 103. The flow control entity 105 is configured to generate a matching flow 106 used for virtual port failure detection.

The local flow control entity 105 is used to configure a matching flow for each virtual port 102, 104 in the system 100. This matching flow can be for ingress or egress communication. It obtains highest priority but no action. The matching flow 106 comprises a default idle timeout value that can be further adapted during a learning period. When the matching flow 106 expires, a failure detection message is generated that notifies the SDN 100 that a virtual port failure has been detected.

The flow control entity 105 learns the traffic patterns and can detect failures based thereon. Therefore, the default timeout value in the matching flow 106 can vary in dependence on the data traffic pattern discovered by the local flow control entity 105 in the learning procedure. For instance in the learning phase, when the matching flow 106 expires while the data traffic has already passed, the flow control entity 105 might adjust the timeout value. This adjustment is repeated for a predetermined number to find a minimum timeout value that needs to be set to allow a data transmission with propagation losses that are typical for this communication scenario and based on the application port and its traffic pattern. The flow control entity 105 detects failure to send traffic from a port 102, 104 due to load or exceptions. The flow control entity 105 detects a non-responsive application based on a detected application port failure. The flow control entity 105 detects that no traffic comes in, e.g. in case a network node 101, 103 is shut off. Granularity is still good if better detection measures are used.

The flow control entity 105 has full overlay topology view, meaning it has visibility on the packet path between the first node 101 and the second node 103 and it can query the data packets along this path. The flow control entity 105 can inject OAM traffic in various points along the path between the first node 101 and the second node 103 to handle the packet arrival on the respective other side by a SDN application. The flow control entity 105 is able to pin point where traffic is lost and can test various traffic types and patterns. The flow control entity 105 is aware of a content-management- system (CMS) configuration. A content management system is a computer application that allows publishing, editing and modifying content, organizing, deleting as well as maintenance from a central interface. The flow control entity 105 can detect misconfigurations such as service configurations for a firewall or a load balancer or a dynamic host configuration protocol (DHCP), or a Network Address Translation (NAT) and/or a Domain Name System (DNS).

The matching flow 106 comprises a destination address of the network node 101, 103 to be observed. The destination address can for instance be a OpenFlow port number. Thus, a traffic loss is detected. The destination address can alternatively or additionally be the service TCP/UDP port number. This is configured by a cloud/services orchestration. Learning Mechanism using Deep Packet inspection (DPI) can be applied to detect the services behind the network node 101, 103 and apply the matching flow 106 automatically.

In Fig. 2, a system 100 according to a first specific embodiment of the present invention is shown. Therein the system 100 is a virtual overlay system 203. The virtual overlay system 203 overlays a logical topology 202 and a physical topology 201. The flow control entity 105 can correlate the physical topology 201 and software infrastructure with the logical topology 202 by using the inventive port failure detection service. The matching flow 106 in the flow control entity 106 is configured to detect different fault scenarios. The matching flow 106 detects that no traffic on the specific ports 102, 104 is obtained. This is achieved by using a default idle-timeout value. Upon installation of the matching flow 106, a timer event starts. In case no traffic is obtained at the observed port 102, 104 during the set default time, the matching flow 106 indicates that the timeout value expires. Thus, upon reaching a timer value that is equal or above the timeout value a port failure is detected.

Furthermore, the matching flow 106 is used to investigate on which OSTlayer the port is inactive. Therefore the matching flow 106 preferably configures at least one connection- test packet. A first connection-test-packet might comprise an ARP-packet. In case no response is obtained based on the send ARP-packet, the flow control entity 105 detects a port failure on the data-link layer-2 of the OSI-model.

Another connection-test-packet might comprise a ping-packet. In case no response is obtained based on the send ping-packet, the flow control entity 105 detects a port failure on the network layer 3 of the OSI-model.

Another connection-test-packet might comprise a HTTP-packet. In case no response is obtained based on the send HTTP-request, the flow control entity 105 detects a port failure on the transport layer 4 of the OSI-model.

In a preferred embodiment, the connection-test-packets are combined. Thus, the matching flow 106 comprises specific connection-test-packets that are configured by the flow control entity 105 and include a plurality of different OSI-model layer packets to observe whether one of the connection-test-packets does not obtain a response. Thus, it might occur that a port 102, 104 might provide connectivity at the data-link layer 2, since an ARP response is obtained by the flow control entity 105. It might further occur that the port 102, 104 might also provides connectivity at the network layer 3, since a ping has been responded by the network node 101, 103 which is obtained by the flow control entity 105. It might further occur that the port 102, 104 does not provide connectivity at the transport layer 4, since a HTTP-request has not been responded by the network node 101, 103. Thus, the flow control entity 105 detects a port failure and specifies this failure as a layer 4 failure in port 102 or in port 104. In Fig. 3, a system 100 according to a second specific embodiment of the present invention is shown. Herein the components of the physical topology 201 and the logical topology 202 are described in greater details.

The physical topology 201 might comprise a first computing device 300 and a second computing device 312. These computing devices 300, 312 are physically interconnected by a physical network 313, which might be a cable connection or a wireless connection. The computing devices 300 and 312 might be any physical network node, such as a host computer, a client, a server, a mobile phone or a distribution point in the network 201, such as a physical switch or a physical router. The computing devices 300 and 312 might be the network nodes 101, 103 as described above.

The logical topology 202 is illustrated as a pipeline. A first virtual machine (VM) 301 - that is installed and processed on the first computing device 300 - is logically connected to a second VM 311 - that is installed and processed on the second computing device 312.

Pluralities of logical and virtual instances are arranged on the logical path between the first VM 301 and the second VM 311 in the topology 202.

For instance, security groups (SG) 302, 310 are installed to enable the control of traffic between the VM 301, 311 and specific subnets. Unlike a firewall that is controlled at the operating system (OS) level, a SG is controlled at the network layer and is independent of the OS that is running in the VM 301, 311. Within the SG 302, 310 access control rules are defined, such as a source IP Address, a destination IP Address, a port, a protocol and/or a dedicated action, such as allow or deny.

For instance, virtual switches (VS) 303, 309 are installed to enable the control of traffic between the VM 301, 311. The VS 303, 309 is a software program that allows the VM 301, 311 to communicate with each other and can inspect the different data packets. The VS 303, 309 can be interpreted as virtual ports 102, 104 as described above.

For instance, a virtual router 304 is installed to route the data traffic between the VM 301, 311. For instance, a network access control list (NACL) 305 is provided in the logical path between the VM 301, 311. For instance, a firewall as a service (FWaaS) 306 is provided in the logical path between the VM 301, 311. For instance, a load balancer as a service (LBaaS) 307 is provided in the logical path between the VM 301, 311. For instance, a virtual private network (VPN) 307 is provided in the logical path between the VM 301, 311.

These instances 300 to 312 are only named as an example. Further logical and virtual instances might be used in the logical topology 202 and in the virtual overlay system 203. In the virtual overlay system 203, a few of these instances 300 to 312 are referenced. The first node 101 that refers to the first computing device 300, the second node 103 that refers to the second computing device 312, the virtual port 102 that refers to the first VS 303, the virtual port 104 that refers to the second VS 309, the flow control entity 105 and the matching flow 106 are used as previously described. Additionally, the router 304 is arranged between the first node 101 and the second node 102. The router 304 is equipped with an FWaaS 306.

On the first computing device 300, hereinafter referred to as first node 101, the first VM 301 is installed and runs. The virtual port 102, which is the first VS 303, comprises the SG 302 and a tunnel-bridge (not referenced). On the second computing device 312, hereinafter referred to as second node 103, the second VM 311 is installed and runs. The virtual port 104, which is the second VS 310, comprises the LBaaS 307 and also a tunnel-bridge (not referenced).

An example of port failure detection is now described using the specific embodiment according to Fig. 3. First of all, the local flow control entity 105 generates a match flow 106 that comprises a connection-test-packet, e.g. a ping -packet, and the destination address of the second VM 311. This generated match flow 106 is injected into the first VM 301 by the flow control entity 105.

Secondly, the VM 311 generates an installation- success message to the flow control entity 105 to indicate that a rule to observe an incoming connection-test-packet from VM 301 has been installed in the second node 103 of the VM 311.

Thirdly, the connection-test-package itself is injected into the first node 101 of the VM 301.

Finally, the flow control entity 105 detects whether the connection-test-packet of the VM

301 on the first node 101 has been responded by the VM 311 on the second node 103. In case a ping-packet has been used as a connection-test-packet, the ping-response should be detected by the local flow control entity 105 and a notification message should be generated.

In Fig. 4, a system 100 according to a third specific embodiment of the present invention is shown. In contrast to Fig. 3, the Fig. 4 shows the destination addresses in the logical and virtual overlay system 203 instead of the corresponding instances. To avoid unnecessary repetitions, only the differences between Fig. 3 and Fig. 4 are described hereinafter. The following IPv4 addresses are only examples for destination addresses. Additionally or alternatively, IPv6 compliant destination addresses or MAC addresses can be used. The router 304 is virtually connected to a WAN and is reached via the IPv4 address 172.16.150.31. The router 304 is virtually reached by the VS 303 via the IPv4 address 10.0.0.1. The VM 301 is also reached by the VS 303 via the IPv4 address 10.0.0.11.

The router 304 is further virtually connected to the VS 309 is reached via the IPv4 address 10.30.0.1. The VM 311 is also virtually reached by the VS 309 via the IPv4 address 10.30.0.21.

A smart top of the switches VS 303 and V S309 can be managed by the flow control entity 105 and thus benefit from the same failure detection mechanism. The latency can be measured and all physical paths between the first node 101 and the second node 102 can be detected using the failure detection and the connection-test-packet of the matching flow 106. Additionally, pluggable alerting mechanism can be introduced.

Furthermore, misconfigurations can now be detected easily. Especially, service configurations for the FWaaS 306, the LBaaS 307, the DHCP, the NAT and/or the DNS can be detected using the inventive failure detection mechanism. Also SG and router misconfigurations are detected. In Fig. 5, a system 100 according to a fourth specific embodiment of the present invention is shown. Therein a system 100 is shown that is compliant to the OpenFlow standards. Therein, the generated matching flow 106 of the local flow control entity 105 is injected as a flow entry 502 in a forwarding element 501 of the OpenFlow system 100. The local flow control entity 105 is obtained in a hypervisor instance of the virtual overlay system 203. The first node 101 and the second node 103 each comprise a virtual port 102, 104 which are failure detected as follows. On the first node 101, the first VM 301 is installed and runs. On the second node 103, the second VM 311 is installed and runs. First of all, the local flow control entity 105 generates a matching flow 106 that comprises a connection-test-packet, e.g. an ARP- packet, and the destination address of the second VM 311. This generated matching flow 106 is injected into the first VM 301 by the flow control entity 105. A flow expiry and/or re-configure flow of this matching flow 106 is provided as a flow entry 502 to the forwarding element 501.

Finally, the flow control entity 105 detects whether the connection-test-packet of the VM 301 on the first node 101 has been responded by the VM 311 on the second node 103. In case an ARP-packet has been used as a connection-test-packet, the ARP-response should be detected by the local flow control entity 105 and a notification message should be generated. In case the flow expires before the ARP-response is achieved, the forwarding element 501 generates a respective notification.

Fig. 6 shows a method 1000 for detecting a virtual port failure in a software defined network system 100, according to an embodiment of the present invention. In a first step 1001 of the method 1000, a matching flow 106 is generated by a local flow control entity 105 that is arranged between a first network node 101 and a second network node 103 in the system 100. In a second step 1002, the generated matching flow 106 is injected in a forwarding element 501 of the system 100. In a third step 1003, the matching flow 106 is established between the first node 101 and the second node 103, wherein the matching flow 106 comprises a connection-test-packet using a default idle timeout value. In a fourth step 1004, a virtual port failure is detected upon expiration of the timeout value.

Optionally, in a fifth step 1005 (dashed line in Fig. 6), a successful receipt of the connection-test-packet is reported in case the timeout value is not expired upon receiving of the connection-test-packet. In summary, by the proposed system 100 and method 1000, the present invention provides a failure detection mechanism that leverages idle timeout mechanism to detect virtual port failures and/or load conditions. This failure detection service is commonly supported in VS and easily integrated with a local flow control entity 105. The approach is non-intrusive, since the flow control entity 105 installs a matching flow 106 without further actions and the flow control entity 105 learns with different timeout values to adjust the timeout to a minimum timeout value. For the learning procedures, traffic patterns and application ports are observed. The best granularity for failure detection is obtained since the problems are spotted closest to the virtual port and not centrally. The flow control entity 105 of all described embodiments might learn the average traffic pattern between the first node 101 and the second node 103. It configures with best granularity timeout values based on the average traffic pattern.

In case the match flow 106 expires, the flow control entity 105 detects a port failure, which can be ingress, egress or both. A safety measure can be provided to re-configure the timer and wait for a second expiry before generating a notification/report on the port failure detection.

Subsequent, the flow control entity 105 is configured to inform the user that a port failure has been detected. Additionally, an automatic remediation can be configured and/or the flow control entity 105 can re-route the traffic on failure detection, e.g by using OpenFlow standardized procedures.

The results of the failure detection can trigger an auto remediation locally or from the flow control entity 105. A result could be to block all port traffic, e.g. if an application failure pattern is detected. Alternatively or additionally, the blocking of all traffic might trigger an upper layer mechanism, such as a LBaaS 307, to direct the traffic to a different network node.

The inventive concept describes various ways to detect failure on a virtual port 102, 104. It can be detected that no traffic at all is obtained from the observed port 102, 104 or it can detect certain application traffic losses, e.g. based on an OSI-layer based connection- test-packet.

In a failure case, the observed service itself, or the application do not send data traffic due to various reasons. This is detected by the failure detection service as described. Since the network node 101, 103 could still send management data or other data traffic via another application, it is important to detect the complete port situation. This would be possible via a low-layer connection-test-packet, such as a ping or an ARP in the match flow 106 according to the invention. To identify the faulty application out of plurality of applications, the user might know what applications and/or services are actually running on the specific port 102, 104. Thus it can be configured by a DPI integration which flow to match on.

In case a traffic loss is detected, it could be assumed that the main traffic stream in the network node 101, 103 is the application data traffic. When the match flow 106 expires an injection of various connection-test-packets can be started to check a specific port 102, 104 of the network node 101, 103 to detect what specific application is down.

It should be noted that the system 100 is not restricted to two network nodes 101, 103. Further network nodes or intermediate network nodes could be applied in the system 100.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A software defined network system (100) comprising: a first network node (101) comprising at least one virtual communication port

(102); a second network node (103) comprising at least another virtual communication port (104), wherein the first network node (101) and the second network node (103) are configured to exchange data over their virtual communication ports (102, 104); and a flow control entity (105) locally arranged between the first network node (101) and the second network node (103), wherein the flow control entity (105) is configured to generate a matching flow (106) used for virtual port failure detection.

2. The system (100) according to claim 1, wherein the system (100) is a virtual overlay system (203) in a system that further comprises physical system topology (201) and software infrastructure with logical system topology (202).

3. The system (100) according to claim 1 or 2, wherein the generated matching flow (106) of the local flow control entity (105) is injected as a flow entry (502) in a forwarding element (501) of the system (100).

4. The system (100) according to one of the preceding claims, wherein the generated matching flow (106) of the local flow control entity (105) comprises a destination address of the first network node (101) or the second network node (102) and further comprises a connection-test-packet.

5. The system (100) according to one of the preceding claims, wherein the flow control entity (105) is locally arranged on the first node (101) side to detect a virtual port failure of the first node (101) or the second node (103); and/or wherein the flow control entity (101) is locally arranged on the second node (103) side to detect a virtual port failure of the first node (101) or the second node (103); and/or wherein the flow control entity (105) is locally arranged in a virtual element between the first node (101) and the second node (103) to detect a virtual port failure of the first node (101) or the second node (103).

6. The system (100) according to one of the preceding claims, wherein the generated matching flow (106) of the local flow control entity (105) comprises a default idle timeout value; and wherein upon expiration of the idle timeout value a virtual port failure is detected.

7. The system (100) according to claim 6, wherein the default idle timeout value is adjusted by the local flow control entity (105) according to specific data pattern of the system (100).

8. The system (100) according to one of the preceding claims, wherein the generated matching flow (106) of the local flow control entity (105) is configured to measure a data exchange latency time value between the first node (101) and the second node (103).

9. The system (100) according to one of the preceding claims, wherein the generated matching flow (106) of the local flow control entity (105) is used to detect a traffic loss or is used to inject connection-test-packets between the first node (101) and the second node (103) at a specific layer in the open system interconnection model.

10. The system (100) according to one of the preceding claims, wherein the local flow control entity (105) is configured to correlate the physical system topology (201) and the software infrastructure with the logical system topology (202).

11. The system according to one of the claims 2 to 10, wherein the local flow control entity (105) is configured to inject object access method related traffic in the matching flow (106).

12. The system according to one of the preceding claims, wherein the local flow control entity (105) is configured to detect a misconfiguration of the system (100).

13. A method (1000) for detecting a virtual port failure in a software defined network system (100), the method (1000) comprising the steps of: generating (1001) a matching flow (106) by a local flow control entity (105) that is arranged between a first network node (101) and a second network node (103) in the system (100); injecting (1002) the generated matching flow (106) in a forwarding element (501) of the system (100); establishing (1003) the matching flow (106) between the first node (101) and the second node (103), wherein the matching flow (106) comprises a connection-test-packet using a default idle timeout value; and detecting (1004) a virtual port failure upon expiration of the timeout value.

14. The method (1000) according to claim 13, further comprising the step of: reporting (1005) a successful receipt of the connection-test-packet in case the timeout value is not expired upon receiving of the connection-test-packet.

15. Computer program product for implementing, when carried out on a computing device, a method (1000) for detecting a virtual port failure according to one of the claims 13 or 14.