WO2017080610A1

WO2017080610A1 - Openflow compliant network with flow expiry extension

Info

Publication number: WO2017080610A1
Application number: PCT/EP2015/076514
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: CN108353037A

Abstract

The present invention relates to an OpenFlow compliant network system 100 that comprises at least one forwarding element 101 that comprises an OpenFlow compliant channel interface 102; and an OpenFlow compliant controlling element 103 configured to communicate with the at least one forwarding element 101 via the OpenFlow compliant channel interface 102, wherein the controlling element 103 is configured to define a first data flow entry 104 and a second data flow entry 105 in the forwarding element 101, wherein the first data flow entry 104 and the second data flow entry 105 both represent a bidirectional data connection 106, and wherein the controlling element 103 is further configured to define an expiry relationship 107 between the first data flow entry 104 and the second data flow entry 105.

Description

OPENFLOW COMPLIANT NETWORK WITH FLOW EXPIRY EXTENSION

TECHNICAL FIELD

The present invention is in the technical field of Software defined networks, SDN, and especially relates to an OpenFlow compliant network system, a method for managing data flows in an OpenFlow compliant network system and a computer program product for implementing said method when carried out on a computing device. In particular, the present invention suggests to define an expiry relationship between data flow entries or group entries that represent one single bidirectional connection in an OpenFlow compliant network system.

BACKGROUND

SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is achieved 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 or forwarding plane). Such a network topology simplifies the networking. SDN requires some method for the control plane to communicate with the data plane. One such mechanism is called OpenFlow. Thus, OpenFlow is a communications protocol that gives access to the forwarding plane of a forwarding element in such a SDN. OpenFlow enables controlling elements to determine the path of data packets through the forwarding plane. The achieved separation of the control plane from the forwarding plane allows a more sophisticated traffic management than using simple access control lists, ACLs, and routing protocols. OpenFlow allows switches from different suppliers - often each with their own proprietary interfaces and scripting languages - to be managed remotely using a single, open protocol interface, the OpenFlow channel. OpenFlow is thus considered as an enabler of SDN.

The OpenFlow compliant network system allows a remote administration of Open Systems Interconnection, OSI, Transmission Control Protocol, TCP, layer 3 data flow tables that are deposited in a forwarding element. The remote administration especially contains an adding, modifying, updating and/or removing of data flow entries in such data flow tables. A data flow entry in such forwarding element is especially a data flow matching rule and/or a data flow related action. An OpenFlow compliant network system preferably prescribes the use of Transport Layer Security, TLS.

In White Paper "OpenFlow Switch Specification" ', Version 1.4.0 of October 14^th, 2013, retrievable from the Open Networking Foundation website "https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openflow/openflow-spec-vlA.O.pdf" it is described that a forwarding element in the OpenFlow protocol consists of one or more data flow tables and a group table that perform data packet lookups and data packet forwarding, and an OpenFlow channel to an controlling element that is arranged external from the forwarding element. Using the OpenFlow protocol, the controlling element can administrate each data flow entry in the data flow tables, both reactively (in response to data packets) and proactively using the OpenFlow compliant channel interface. Each data flow entry in the data flow table consists of a match field, a counter filed and a set of instructions to apply to matching data packets.

Thus, routing decisions can be made periodically or ad hoc by the controlling element and translated into data flow rules and actions with a configurable lifespan, which are then deployed to the data flow table in the forwarding element, leaving the actual forwarding of matched data packets to the forwarding element at wire speed for the duration of those rules. Data packets which are unmatched by the forwarding element can be forwarded to the controlling element. The controlling element can then decide to modify the existing data flow table rules in one or more of the forwarding elements or to deploy at least one new data flow rule, to prevent a structural data flow of traffic between the forwarding element and the controlling element. It could also be decided by the controlling element to forward the data packets itself.

A data flow entry can be removed from the data flow tables either at a request of the controlling elements or via the forwarding elements upon detection of a flow expiry mechanism.

The forwarding element flow expiry mechanism runs at the forwarding element independently of the controlling element and is based on the state and configuration of the data flow entry itself. Each data flow entry has an IDLE_TIMEOUT value and a HARD_TIMEOUT value associated with it.

A non-zero HARD_TIMEOUT value causes a data flow entry to be removed after a preset number of seconds, regardless of how many data packets already have been matched. Thus, the data flow removal occurs automatically after the preset time duration.

A non-zero IDLE_TIMEOUT value causes a data flow entry to be removed when it has matched no data packets in a preset number of seconds.

According to the OpenFlow standard, the forwarding element has to implement the data flow expiry and has to remove a data flow entry from the data flow table when one of those timeouts is exceeded.

If either the IDLE_TIMEOUT value or the HARD_TIMEOUT value is non-zero in the respective data flow entry, the forwarding element must note the data flow entry's arrival time, as it may need to evict the entry later.

Both current data flow expiry mechanisms are stateless. Thus, there exists no interconnection or relationship between different data flow entries in a data flow table of a forwarding element. Thus, especially bidirectional connections are heavily underprivileged. This has several drawbacks, especially when special kinds of applications should be performed in the OpenFlow network system.

To provide high availability, HA, services or applications, special HA protocols in the network nodes are implemented or are achieved with external load balancers. Those mechanisms require a constant health checking between the clustered network nodes to detect any network failure. The same applies by using OpenFlow multi-controlling architectures.

To provide a load balancing, LB, mechanism, further external elements are required in the data path to detect any network failure, such as a connection failure.

Every external element in the OpenFlow compliant network system requires additional pay load and thus decreases the efficiency of the systems performance per se. The network system complexity is disadvantageously increased and the resulting data rates are decreased when administrating, supporting and/or running these further external elements. Additional protocols are needed to detect a failure in the data path connections by using health checking mechanism, which introduce latency problems and which are hard to configure for the expected behavior.

Thus, there is a need to avoid such external elements, especially for the HA- or LB- services/applications. Especially, a detection of non-responsive data connections should be based on an internal OpenFlow mechanism with an easy topology and on an easy manner. Additionally, there is a need to mark a relationship between two data flow entries in a data flow table of a forwarding element to increase the systems performance.

SUMMARY In view of the above-mentioned problems and disadvantages, the present invention aims to improve the state of the art, particularly the flow expiry mechanism described above.

The present invention has the object to increase the detection rate of connection failures in bidirectional data connections of an OpenFlow compliant network system, preferably in HA- and LB-applications. Thereby, the present invention seeks to avoid producing a massive overhead and provides a non-intrusive approach. 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 an internal OpenFlow flow expiry mechanism. The inventive flow expiry mechanism is obtained by integration in the OpenFlow standard procedures. Thus, each SDN application can find many use cases to use the invention to better control the data traffic within the OpenFlow system. Especially, a HA- application can be defined for important data flows, where the connection failure is inventively detected locally without any further external element. Those applications can manage restrict rules for the latency needed between different network nodes and rollback to another network node in case of a failure. Also a dynamic LB is introduced that reacts according to a response time from a network node, such as a server. HA- or LB applications for multi-controlling elements are applicable that perform learning analytics to learn the data traffic characteristics to determine the best granularity in the system. The term granularity is related to the amount of computation in relation to the amount of communication, preferably, the ratio of computation to communication. Then any abnormal behavior on the data path, such as data traffic that is not passing to/from a specific network node, is somehow triggered and countermeasures can be applied.

A first aspect of the present invention provides an OpenFlow compliant network system that comprises at least one forwarding element that comprises an OpenFlow compliant channel interface and an OpenFlow compliant controlling element configured to communicate with the at least one forwarding element via the OpenFlow compliant channel interface, wherein the controlling element is configured to define a first data flow entry and a second data flow entry in the forwarding element, wherein the first data flow entry and the second data flow entry both represent a bidirectional data connection and wherein the controlling element is further configured to define an expiry relationship between the first data flow entry and the second data flow entry.

In the system of the first aspect, a novel OpenFlow extension is introduced and used. The controlling element configures a first data flow entry and a second data flow entry that both represent one single bidirectional data connection. The controlling element further defines an expiry relationship between the first data flow entry and the second data flow entry representing the single bidirectional data connection. This expiry relationship can be considered as a new data flow rule defined by the controlling element in order to detect non-responsive data connections and to mark a relationship between two data flow entries that belong to the same bidirectional connection. A forwarding element in the OpenFlow compliant network system might be a connection point or a redistribution point. In the inventive OpenFlow network system, the forwarding element might be data communication equipment (DCE) such as a modem, hub, bridge or switch. The forwarding element might preferably be an active electronic device that is attached to the OpenFlow network system and that is capable of creating, receiving, or transmitting information over a physical, logical and or virtual communications channel. The forwarding element is preferably configured to route a data packet between two network nodes using data flow rules defined by the controlling element and deposited in the data flow table of the forwarding element. Preferably, the forwarding element is a virtual switch, such as a virtual multilayer network switch, designed to enable effective network automation through programmatic extensions, while supporting also other standard management interfaces and protocols such as NetFlow, sFlow, SPAN, RSPAN, CLI, LACP and 802. lag or a virtual machine, which is an emulation of a particular computer system that operate 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 controlling element according to the invention is an entity in the OpenFlow compliant system that is configured to provide a unified network control plane offering global programmability to deploy dynamic services across the network system. The controlling element leverages the OpenFlow standard to abstract the network data plane from the control plane, and to centralize network control logic and intelligence into a common, highly available server. Centralization and abstraction using an OpenFlow compliant controlling element enables administrators and applications to directly access and control network nodes and/or forwarding elements.

The forwarding element and the controlling element are configured to communicate via an Openflow compliant interface, also referred to as OpenFlow channel. The OpenFlow channel is the interface that connects the forwarding element to the controlling element. Through this interface, the controlling element is used to configure and manage the forwarding element, receives events from the forwarding element, and sends data packets out the forwarding element. Between the data path and the OpenFlow channel interface, the interface is implementation-specific, thus the OpenFlow channel messages must be formatted according to the OpenFlow protocol. The OpenFlow channel is preferably encrypted using TLS, but may be run directly over TCP. An expiry relationship according to the invention is a relationship between the first data flow entry and the second data flow entry on an expiry event. Thus, when a first data flow is matched in the forwarding element, a corresponding second data flow entry starts a flow-expiry event. Thus, state fullness and relationships between different data flows are achieved. The expiry-relationship is preferably inserted as an instruction rule in the respective data flow field. Each data flow entry contains a set of instructions that are executed when a data packet matches the data flow entry. The instruction results in a change to the packet, an action set and/or pipeline processing. Thus, upon matching of the first data flow in the forwarding element, the expiry-relationship extension as an instruction rule causes to trigger a flow-expiry event of the related second data flow entry.

Thus, instead of defining one data flow entry for a bidirectional connection, two data flow entries are defined that represent the bidirectional connection and both data flow entries are linked in that if either one of the data flows cannot be matched, the other one of the related data flow entries recognizes it and can trigger additional functions, such as reporting, deleting and so on.

Thus, the inventive OpenFlow extension enables SDN applications or controlling elements to address various different use cases without the need of further external elements. For instance a HA application can be defined for important bidirectional data connections that is enforced locally in the forwarding element. The HA application does not need an external health checking. It is additionally possible to provide a smart distribution between different OpenFlow controlling elements. It is additionally possible to provide a distributed LB service that detects a data connection failure or a latency issue in a local manner.

This leads to a better granularity on a failure detection that is closer to a specific network node, especially a client node. No additional external computing entity, such as a central processing unit, is needed. The inventive concept fits with the OpenFlow standard without the need for additional adaption. The inventive solution is implemented easily in both software and hardware forwarding elements.

In a first implementation form of the system according to the first aspect, the controlling element is configured to define the first data flow entry for representing a forward direction of the bidirectional data connection between a first node and a second node in the network system via the forwarding element and the controlling element is configured to define the second data flow entry for representing a backward direction of the bidirectional data connection between the second node and the first node in the network system via the forwarding element.

The first node and/or the second node is network node in the system that might be a communication endpoint of terminal equipment, preferably a data terminal equipment (DTE) such as a digital telephone handset, a printer or a host computer, for example a workstation, a virtual machine, a client or a server node. The definition of a network node depends on the network and protocol layer referred to. A 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 communications channel. A passive distribution point such as a distribution frame or patch panel is consequently not a network node according to the invention.

Each node in the OpenFlow system 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, 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 media access control protocol sub-layer of the OSI reference model. Such an address might alternatively be an Internet Protocol, IP, address, which is a numerical label assigned to each network node participating in the network system that uses the Internet Protocol for communication. An IP address serves two principal functions: host or network interface identification and location addressing.

The definition of a data flow entry for each direction of a bidirectional data connection allows the detection of a failure of either one direction of the data connection independent on the respective other direction. In case, one of the data flows cannot be matched within the expiry rule as defined in the expiry relationship, for instance because of a non- responsive connection between the first node and the forwarding element or a non- responsive connection between the second node and the forwarding element, both data flows are interrelated for further actions without further additional commands or any further external element. 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, a match field in the first data flow entry is different to a match field in the second data flow entry.

Thus, the match fields of the expiry-related data flow entries can comprise different data entries. On receipt of a data packet for one of these expiry-related data flow entries, the forwarding element starts by performing a table lookup. A data packet match field is extracted from the packet and typically includes various data packet header fields, such as an Ethernet source addressor IPv4 or IPV6 destination address. In addition to packet headers, matches can also be performed against the ingress port and metadata fields.

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 expiry relationship is defined by a timer between the first data flow entry and the second data flow entry.

The inventive timer is preferably inserted in the data flow table in the forwarding element and is set in conjunction with one of the flow-expiry timeout field (native timers) of the data flow entry according to the OpenFlow standard. Thus, this timer could also define either a maximum amount of time (HARD_TIMEOUT) or an idle time (IDLE_TIMEOUT) before the data flow is expired. Thus, the defined data flow entries are also configured to support these native timers.

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, both, the first data flow entry and the second data flow entry are deleted if the expiry relationship indicates the expiry.

Thus, in case one of the data flow entries cannot be matched by the forwarding element or the controlling element, both data flow entries are automatically deleted due to the expiry relationship data flow rule without any external elements assistance which leads to less system complexity and an improved health checking of a bidirectional connection. Each of the first to fourth implementation form demonstrate the expiry-relationship between a first data flow entry and a second data flow entry, one for each direction of the connection. A challenge that needs to be solved with these implementation forms is the presetting of an appropriate timeout-value. In case this timeout-value is too small, it might fit to the data connection establishing but not for slower operations on a nodes side. In case this timeout- value is too big, granularity of failure and latency detection might be lost. This challenge is addressed with a fifth implementation form of the system.

In a fifth implementation form of the system according to the first aspect, the controlling element is configured to define an expiry relationship between at least a first group entry and a second group entry instead of defining an expiry relationship between the first data flow entry and the second data flow entry. Instead of defining an expiry-relation between single data flow entries that represent a bidirectional connection, an expiry-relationship between group entries of data flows is defined.

A group entry is preferably defined in the group table of forwarding element. The group table represents a specific kind of network node that operates in the network system, such as a client node as a type of network node or a server node as another type of network node. Execute all buckets in the group. This group can also be used for multicast or broadcast forwarding. The packet is effectively cloned for each bucket; one data packet is processed for each bucket of the group. If a bucket directs a data packet explicitly out the ingress port, this packet clone is dropped.

The ability for a data flow entry to point to a group enables OpenFlow to represent additional methods of forwarding, e.g. selecting all in a group. Thus, a plurality of data flows can now be expiry-related and the mean time of data flows instead of a single data flow observation is obtained. Thus, extreme values due to latency problems of one specific data flow can be ignored and no countermeasures are provided until the whole group is concerned.

In a sixth implementation form of the system according to the fifth implementation form of the first aspect, the first group entry and the second group entry share a single time.

This allows an alignment of time values and avoids the setup of different timer values that need to be observed and thus would require additional resources. A timer-expired- notification is preferably sent from the forward element to the controlling element, in case of a detection of a group-timer-expiry. The controlling element is configured to identify and act accordingly and to perform countermeasure.

In a seventh implementation form of the system according to the sixth implementation form of the first aspect, a data flow match in the first group entry causes the timer to be triggered in case the timer is void.

Thus, in case a timeout- value of a timer has not been started, the system triggers the timer in order to observe the data connection of the respectively related data flows from the specific group. In an eighth implementation form of the system according to the seventh implementation form of the first aspect, a data flow match in the first group entry causes the timer to be continued, in case the timer has already been triggered.

Thus, in case a timeout-value of a timer has already been started, the system leaves the timer unchanged since a first data flow match has already been recognized and timer is already triggered.

In a ninth implementation form of the system according to any of the sixth implementation form to the eighth implementation form of the first aspect, a data flow match in the second group entry causes the timer to be reset. Thus, in case a respectively related data flow is matched in the forwarding element, the flow-expiry is stopped if the timeout-value of a timer has not been exceeded and a responsive-connection is detected.

Especially the sixth to ninth implementation forms solve the above addressed problem according the presetting of the perfect timeout value of a timer in a flow-expiry- relationship. By defining data flow groups it is possible to reset a timer by data flows also in case a specific data flow in the group hits a slow operation and thus would lead to a data flow expiry. Thus, it is now possible to define a lower granularity timeout value and hence achieve better failure and latency detections. This kind of group definition fits well into virtualized production environment, preferably by a higher number of data flow entries within a group, also data flows even on the same compute node and it preferably fits for LB applications between service chaining functions.

A second aspect of the present invention provides a method for managing data flows in an OpenFlow compliant network system, the method comprising the steps of: defining, by a controlling element, a first data flow entry in a forwarding element of the system, defining, by the controlling element, a second data flow entry in the forwarding element of the system, wherein the first data flow entry and the second data flow entry both represent a bidirectional data connection between a first node and a second node of the system and defining, by the controlling element, an expiry relationship between the first data flow entry and the second data flow entry. In a first implementation form of the method according to the second aspect as such, the controlling element is configured to define the first data flow entry for representing a forward direction of the bidirectional data connection between a first node and a second node in the network system via the forwarding element and the controlling element is configured to define the second data flow entry for representing a backward direction of the bidirectional data connection between the second node and the first node in the network system via the forwarding element.

In a second implementation form of the method according to the second aspect as such or according to any previous implementation form of the second aspect, a match field in the first data flow entry is different to a match field in the second data flow entry.

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 expiry relationship is defined by a timer between the first data flow entry and the second data flow entry.

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, both, the first data flow entry and the second data flow entry are deleted if the expiry relationship indicates the expiry.

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 method for managing data flows in an OpenFlow compliant network system, the method comprising the steps of: defining, by a controlling element, a first group entry in a forwarding element of the system, defining, by the controlling element, a second group entry in the forwarding element of the system, wherein the first group entry and the second group entry both represent a bidirectional data connection between a first node and a second node of the system, and defining, by the controlling element, an expiry relationship between the first group entry and the second group entry.

In a first implementation form of the method according to the third aspect, the first group entry and the second group entry share a single timer. In a second implementation form of the method according to the first implementation form of the third aspect, a data flow match in the first group entry causes the timer to be triggered in case the timer is void.

In a third implementation form of the method according to the second implementation form of the third aspect, a data flow match in the first group entry causes the timer to be continued, in case the timer has already been triggered.

In a fourth implementation form of the method according to any of the sixth implementation form to the eighth implementation form of the third aspect, a data flow match in the second group entry causes the timer to be reset. The method of the third aspect achieves all advantages described above for the system of the first aspect.

A fourth aspect of the present invention provides a computer program product for implementing, when carried out on a computing device, a method for managing data flows according to the second aspect or the third 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 flow chart of a method according to a first specific embodiment of the present invention.

Fig. 5 shows a flow chart of a method according to a second specific embodiment of the present invention.

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

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

Fig. 8 shows a system according to a fifth specific 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 an Openflow compliant network system 100 that comprises at least one forwarding element 101 and an OpenFlow compliant controlling element 103. The forwarding element 101 comprises an OpenFlow compliant channel interface 102. The controlling element 103 is configured to communicate with the at least one forwarding element 101 via the OpenFlow compliant channel interface 102. In the system 100, the controlling element 103 is configured to define a first data flow entry 104 and a second data flow entry 105. Those data flow entries 104, 105 are provided to the forwarding element 101. The first data flow entry 104 and the second data flow entry 105 both represent a bidirectional data connection 106 (not shown in Fig. 1).

The controlling element 103 is further configured to define a flow-expiry relationship 107 between the first data flow entry 104 and the second data flow entry 105. This expiry relationship 107 can be considered as a new data flow rule defined by the controlling element 103 in order to detect non-responsive data connections and to mark a relationship between the two data flow entries 104, 105 that belong to the same bidirectional connection 106.

The forwarding element 101 is preferably configured to route a data packet between two network nodes (not shown) using data flow rules defined by the controlling element 103.

Preferably, the forwarding element 101 is a virtual switch. The forwarding element 101 preferably comprises a storage means for depositing the first data flow entry 104, the second data flow entry 105 and the expiry -relationship 107, preferably as respective entries in a lookup-table. The flow-expiry-relationship 107 might preferably be an instruction rule for a data flow entry.

In case a data flow matches with one of the data flow entries 104, 105 in the forwarding element 101, it is checked whether this data flow is interrelated with another data flow entry in the forwarding element 101 and upon detection of such an interrelation, a corresponding flow-expiry mechanism is activated. This system 100 leads to a better granularity on a failure detection that is closer to a specific network node, especially a client node (not shown in Fig. 1). No additional computing entity, such as a central processing unit, is needed. The inventive concept fits with the OpenFlow standard without the need for additional adaption. The inventive solution is implemented easily in both software and hardware forwarding devices. In Fig. 2, a system 100 according to a first specific embodiment of the present invention is shown. In addition to the basic embodiment according to Fig. 1, the system 100 according to Fig. 2 comprises a first node 108 and a second node 109.

The first node 108 and the second node 109 may either be a DCE such as a modem, hub, bridge or switch or more preferably 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 108 and the second network node 109 are configured to exchange data over their virtual communication ports (not shown). The virtual communication port is a dedicated network connection for each network node in the system 100. It gives network nodes 108, 109 and applications on the network node 108, 109 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 are customized to each network nodes 108, 109 requirements. Each node 108, 109 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 first node 108 and the second node 109 exchange information and/or data via a bidirectional connection 106, shown with a dashed line. The bidirectional connection 106 is physically routed via the forwarding element 101.

In case the first node 108 initially wants to exchange data packets with the second node 109 via the bidirectional connection 106 it establishes a communication link 106a to the forwarding element 101. The forwarding element 101 does not include any data flow entry for such a communication connection 106 and thus forwards relevant data of the data packet or the data packet itself to the controlling element 103 via the OpenFlow channel 102. The controlling element 103 then determines a source address and a destination address from the data packet. Based on that information the controlling element 103 defines a first data flow entry 104 and a second data flow entry 105. Due to the bidirectional character of the connection 106, the controlling element 103 also defines a flow-expiry-relationship 107 between the first data flow 104 and the second data flow 105. The first data flow entry 104, the second data flow entry 105 and the flow-expiry relationship 107 are deposited in the forwarding element 101 via the OpenFlow channel 102. The expiry -relationship 107 can be added in the first data flow entry 104 or the second data flow entry 105 of the data flow table (not shown) as an extension, such as an instruction rule in the set of instruction field of each of the data entries 104, 105.

The first node 108 then establishes a connection 106a that represents a first direction 106a of the bidirectional connection 106 to the forwarding element 101. Based on the defined first data flow entry 104 the forwarding element 101 recognizes a data flow match in its data flow table (not shown) and forwards the data packet of the first direction 106a of the bidirectional connection 106 to the second node 109. Upon data flow match detection according to a first data flow entry 104 the forwarding element 101 also recognizes an expiry-interrelationship 107 between this first data flow entry 104 and a second data flow entry 105 of the forwarding element 101 and triggers a flow-expiry event in the second data flow entry 105. Basically, a timer 111 is started upon sending the data packet from the forwarding element 101 to the second node 109 to trigger the flow-expiry event. The inventive timer 111 might preferably be related to one of the two native timers HARD_TIMEOUT or IDLE_TIMEOUT available in the forwarding element 101 according to the OpenFlow standard. The timeout-value is a default timeout value. Thus, this timer 111 could also define either a maximum amount of time (HARD_TIMEOUT) or an idle time (IDLE_TIMEOUT). Thus, the flow-expiry-relationship 107 according to the data flow entries 104, 105 is also configured to support these native timers.

The second node 109 might establish a connection 106b that represents a second direction 106b of the bidirectional connection 106 to the forwarding element 101. Based on the defined second data flow entry 105 the forwarding element 101 forwards the data packet of the second direction 106b of the bidirectional connection 106 to the first node 108.

In case, no data traffic is obtained by the forwarding element 101 from the second node 109 before an expiration of the timeout-value according to the flow-expiry event, the connection 106b is considered as a non-responsive connection 106b. Accordingly, both, the first data flow entry 104 and the second data flow entry 105 are deleted by the forwarding element 101.

It might be challenging to define an appropriate time-out value for the expiry-relationship 107 between the first data flow entry 104 and the second data flow entry 105. In case this timeout-value is too small, it might fit to the data connection establishing but not for slower operations on a nodes side. In case this timeout-value is too big, granularity of failure and latency detection might be lost.

According to Fig. 3, a system 100 according to a second specific embodiment of the present invention is shown in which this specific challenge is solved. Instead of defining a first data flow entry 104 and a second data flow entry 105 that comprise the predefined expiry-relationship 107, the data flows of a first group 112 and the data flows of a second group 113 comprises the expiry-relationship 107, preferably as one shared timer 111. In contrast to the first specific embodiment according to Fig. 2, in the second specific embodiment according to Fig. 3 a group 112, 113 of data flows 104, 105 is grouped and flow-expiry-related instead of single data flow entries 104, 105. E.g. a client-group or a server-group might be defined. These groups 112, 113 share a single timer 111. By defining data flow groups 112, 113 it is possible to reset a timeout-value of a timer

111 by data flows 104, 105 also in case a specific data flow 104, 105 in the group 112, 113 hits a slow operation and thus would lead to an unwanted data flow expiry. Thus, it is now possible to define a lower granularity timeout- value for the timer 111 and hence achieve better failure and latency detections. This kind of group definition fits well into virtualized production environment, preferably by a higher number of data flow entries 104, 105 within a group 112, 113, also data flows 104, 105 even on the same compute node and it preferably fits for LB applications between service chaining functions.

Fig. 4 shows a method 400 for managing data flows in an OpenFlow compliant network system 100, according to a first specific embodiment of the present invention. In a first step 401 of the method 400, a first data flow entry 104 is defined in a forwarding element 101 of the system 100 by a controlling element 103. In a second step 402 a second data flow entry 105 is defined by the controlling element 103 in the forwarding element 101 of the system 100. The first data flow entry 104 and the second data flow entry 105 both represent a bidirectional data connection 106 between a first node 108 and a second node 109 of the system 100. In a third step 403 an expiry relationship 107 between the first data flow entry 104 and the second data flow entry 105 is defined by the controlling element 103.

Fig. 5 shows a method 500 for managing data flows in an OpenFlow compliant network system 100, according to a second embodiment of the present invention. In a first step 501 of the method 500, a first group entry 112 is defined in a forwarding element 101 of the system 100 by a controlling element 103. In a second step 502 a second group entry 113 is defined by the controlling element 103 in the forwarding element 101 of the system 100. The first group entry 112 and the second group entry 113 both represent a bidirectional data connection 106 between a first node 108 and a second node 109 of the system 100. In a third step 503 an expiry relationship 107 between the first group entry

112 and the second group entry 113 is defined by the controlling element 103. In Fig. 6, a system 100 according to a third specific embodiment of the present invention is shown. The third specific embodiment shows a schematic flow diagram between the first node 108, the second node 109, the forwarding element 101 and the controlling element 103 of the system 100. An initial data flow definition phase is separated from a normal use case phase by a dashed line.

Above the dashed line, an initialization phase of the system 100 is illustrated. Therein the first node 108 provides initially data packets to the second node 109. Therefore, the forwarding element 101 obtains a data packet that comprises source address and destination address in its data packet header. The forwarding element 101 does not include a data flow entry for such a communication connection 106 yet and thus forwards relevant data of the data packet or the data packet itself to the controlling element 103. The controlling element 103 then determines the source address and the destination address from the data packet. Based on that determined information the controlling element 103 performs the method according to Fig. 4 including the defining step 401, the defining step 402 and the defining step 403. Accordingly, the defined first data flow entry 104, the defined second data flow entry 105 and the defined expiry -relationship 107 are transferred to the forwarding element 101 via the OpenFlow channel 102 and deposited in the forwarding element 101.

Below the dashed line, a normal use scenario of the system 100 is illustrated. Therein the first node 108 sends a data packet in a forward direction 106a of a bidirectional connection 106 to the second node 109 via the forwarding element 101. Since the forwarding element 101 comprises the data flow entry 104, it recognizes a data flow match and delivers the data packet via the forward direction 106a to the second node 109. It also recognizes the flow-expiry-relationship between the first data flow entry 104 and a second data flow entry 105 and thus triggers an flow-expiry event as previously described. Thus, upon sending the data packet to the second node 109, the forwarding element 101 triggers the defined flow-expiry event based on the deposited flow-expiry- relationship 107 which is basically the triggering of a timer 111 that comprises a predefined timeout-value. The second node 109 sends a data packet via a backward direction 106b of the bidirectional data connection 106 to the first node 108 via the forwarding element 101. Since the forwarding element 101 comprises the second data flow entry 105, it is able to provide the data packet via the backward direction 106b of the bidirectional connection 106 to the first node 108. Since the data packet from the second node 109 was delivered well before the expiration of the timeout- value of the timer 111 in the forwarding element 101, no connection error is detected.

Thus, a HA application is applicable as a use case according to the third specific embodiment. During initialization: The first node 108 tries to reach a certain virtual network node 109 by sending a data packet on the forward direction 106a of the bidirectional connection 106. The controlling element 103 defines a first data flow entry 104 for the forward direction 106a to match a provided virtual IP and changes it to a destination IP of the second node 109. The controlling element 103 further defines the backward direction 106b of the bidirectional connection 106 and defines the flow-expiry relationship 107 as a data flow entry extension for both, the first data flow entry 104 and the second data flow entry 105.

After initialization: The first node 106 sends the traffic to the virtual IP, the first data flow entry 104 is matched and the traffic is routed to the destination IP of the second node 109. Due to the flow-expiry -relationship 107 between the first data flow 104 and the second data flow 105, the second data flow 105 triggers an aging timer 111. Since the second node 109 responds before timeout, no failure in the connection is detected.

The use of the inventive concept allows a better granularity on failure detection without additional external elements and no additional computing resources. Such a concept is easily implemented via software or hardware. It achieves state fullness and relationships between data flow entries 104, 105.

In Fig. 7, a system 100 according to a fourth specific embodiment of the present invention is shown. The fourth specific embodiment shows a schematic flow diagram between the first node 108, the second node 109, the forwarding element 101 and the controlling element 103 of the system 100. An initial data flow definition phase is separated from a use phase by a dashed line.

Above the dashed line, an initialization phase of the system 100 is illustrated that basically equals the initialization phase according to Fig. 6. The only difference is the fact, that the control element 103 performs the method according to Fig. 5 and thus defines a first group entry 112, a second group entry 113 and a timeout-value 111 as an expiry-relationship 107 by the method steps 501, 502 and 503 which are deposited in the forward element 101 respectively. It should be noted that alternatively the method 400 according to Fig. 4 is applicable and method steps 401, 402, 403 could be performed instead.

The group entries 112, 113 group a plurality of data flows 104, 105 that belong to a group of network nodes, such as clients or servers, especially in the form of virtual machines.

Below the dashed line, an abnormal behavior of the second node 109 is shown. Therein, the timeout value expires at the timer 111 before a data flow matches a second group entry 113 and thus, a non-responsive connection is detected. The first group entry 112 and the second group entry 113 are thus deleted from the forwarding element (illustrated by the crossed references 112, 113). Then, the flow-expiry-event is reported to the controlling element 111 (dashed arrow) or the controlling element 103 knows about the timeout, since it has already defined the expiry-relationship 107 and the preset timeout- value of the timer 111. Upon detection of the flow-expiry (on own behalf or by reporting by the forwarding element 101), the controlling element again performs the defining steps 501, 502, 503 by the method 500 as described in Fig. 5, and deposits the new group entries 112', 113' in connection with the timeout-value 111' in the forward element 101 respectively. It should again be noted that alternatively the method 400 according to Fig. 4 is applicable and method steps 401, 402, 403 could be performed instead.

Next time data traffic reaches the forwarding element 101 and matches with the new first group entry 112' it is directed to another second node 109a instead of the second node 109 and the new flow-expiry-event is triggered, basically by triggering the new timer 111'. Thus, an HA is implemented by using connectivity details from the forwarding element 101 only without external health checking routines. It should be noted that the timeout- values for the shared timer 111 and 111' might be different. In Fig. 8, a system 100 according to a fourth specific embodiment of the present invention is shown. During the initialization phase a first group entry 112, a second group entry 113 and a timeout value 111 is defined using the method according to Fig. 5. It should be noted that alternatively the method 400 according to Fig. 4 is applicable and steps 401, 402, 403 could be performed instead and first data flow entry 104 and second data flow entry 105 is obtained instead. In contrast to Fig. 7, during the initialization phase a new first group entry 112', a new second group entry 113' and a new timeout value 111' is defined using the method according to Fig. 5 (respectively a first data flow entry 104' and second data flow entry 105' , if method 400 according to Fig. 4 is applied). The different group entries 112, 113 and 112' and 113' could be used in view of a priority list in the forwarding element 101.

Accordingly, the data path to the second node 109 and the data path to the other second node 109a are already defined in the forwarding element 101 and can be applied in case a respective timeout value of timer 111 or 111' is expired. Thus, it can be rolled back faster if both options are configured during the initialization phase. If the respective flows are expired they are deleted. The controlling element 103 can reconfigure the deleted flows again in a lower priority. Thus, a systems downtime is minimized. A HA application uses a local state of the system only and does not require further external elements, e.g for a health checking service.

In another use case, a LB application can be achieved with the inventive concept. Using the proposed extension a distributed LB can be defined to second nodes 109, 109a, such as server nodes, according to a response latency of the node. No external application is needed to perform the LB application. To achieve the LB application, a number of data flow entries 104, 105 are defined in the forwarding element 101 from a cluster pool with appropriate priorities. The timeout duration is set according to the latency of each node 109, 109a that should be achieved. As more first nodes 108, such as clients are connecting to the second nodes 109, 109a, as more the respective latency decreases until the timeout-value of the preset timer 111 expires. The first nodes 108, such as client nodes, are then directed to another second node 109a in the cluster while the controlling element 103 updates the expired flows again with different priorities. Thus, a dynamic LB is achieved that is based on response time measured locally.

In summary, by the proposed system 100, the method 400 and the method 500, the present invention provides an OpenFlow extension mechanism that leverages to detect non-responsive connections and deletes appropriate flows from the forwarding element 101 upon flow-expiry detection. Thus, a better granularity on failure detection is achieved that is closer to the respective node 108, 109, especially closer to client nodes of the system 100. No additional computing resource, such as an external CPU is needed. The solution is OpenFlow standard compliant and can easily be inserted in the forwarding elements 101. Different use cases, such as HA or LB can be addressed without further external devices or elements. Especially a health checking can be obtained internally by the inventive flow-expiry extension. Smart distribution between OpenFlow controlling elements 103 is also obtained. Additionally, a distributed LB with appropriate failure detection and latency issues is achieved.

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

CLAIMS What we claim is:

1. An OpenFlow compliant network system (100) comprising: at least one forwarding element (101) that comprises an OpenFlow compliant channel interface (102); and an OpenFlow compliant controlling element (103) configured to communicate with the at least one forwarding element (101) via the OpenFlow compliant channel interface (102), wherein the controlling element (103) is configured to define a first data flow entry (104) and a second data flow entry (105) in the forwarding element (101), wherein the first data flow entry (104) and the second data flow entry (105) both represent a bidirectional data connection (106), and wherein the controlling element (103) is further configured to define an expiry relationship (107) between the first data flow entry (104) and the second data flow entry (105).

2. The system (100) according to claim 1, wherein the controlling element (103) is configured to define the first data flow entry (104) for representing a forward direction (106a) of the bidirectional data connection (106) between a first node (108) and a second node (109) in the network system (100) via the forwarding element (101), and wherein the controlling element (103) is configured to define the second data flow entry (105) for representing a backward direction (106b) of the bidirectional data connection (106) between the second node (109) and the first node (108) in the network system (100) via the forwarding element (101).

3. The system (100) according to one of the previous claims, wherein a match field (110a) in the first data flow entry (104) is different to a match field (110b) in the second data flow entry (104).

4. The system (100) according to one of the previous claims, wherein the expiry relationship (107) is defined by a timer (111) between the first data flow entry (104) and the second data flow entry (105).

5. The system (100) according to claim 4, wherein the timer (111) is triggered upon recognizing a data flow match between a first node (104) and a second node (105).

6. The system (100) according to one of the previous claims, wherein both, the first data flow entry (104) and the second data flow entry (105) are deleted if the expiry relationship (107) indicates the expiry.

7. The system (100) according to claim 1, wherein the controlling element (103) is configured to define an expiry relationship (107) between at least a first group entry (112) and a second group entry (113) instead of defining an expiry relationship (107) between the first data flow entry (104) and the second data flow entry (105).

8. The system (100) according to claim 7, wherein the first group entry (112) and the second group entry (113) share a single timer (111).

9. The system (100) according to claim 8, wherein a data flow match in the first group entry (112) causes the timer (111) to be triggered in case the timer (111) is void.

10. The system (100) according to claim 9, wherein a data flow match in the first group entry (112) causes the timer (111) to be continued, in case the timer (111) has already been triggered.

11. The system (100) according to claims 8 to 10, wherein a data flow match in the second group entry (113) causes the timer (111) to be reset.

12. A method (400) for managing data flows in an OpenFlow compliant network system (100), the method (400) comprising the steps of: defining (401), by a controlling element (103), a first data flow entry (104) in a forwarding element (103) of the system (100), defining (402), by the controlling element (103), a second data flow entry (105) in the forwarding element (101) of the system (100), wherein the first data flow entry (104) and the second data flow entry (105) both represent a bidirectional data connection (106) between a first node (108) and a second node (109) of the system (100), and defining (403), by the controlling element (103), an expiry relationship (107) between the first data flow entry (104) and the second data flow entry (105).

13. A method (500) for managing data flows in an OpenFlow compliant network system (100), the method (400) comprising the steps of: defining (501), by a controlling element (103), a first group entry (112) in a forwarding element (103) of the system (100), defining (502), by the controlling element (103), a second group entry (113) in the forwarding element (101) of the system (100), wherein the first group entry (112) and the second group entry (113) both represent a bidirectional data connection (106) between a first node (108) and a second node (109) of the system (100), and defining (503), by the controlling element (103), an expiry relationship (107) between the first group entry (112) and the second group entry (113).

14. The method according to claim 13, wherein the first group entry (112) and the second group entry (113) share a single timer (111).

15. Computer program product for implementing, when carried out on a computing device, a method for managing data flows according to one of the claims 12 to 14.