WO2017097352A1

WO2017097352A1 - Managing a network through connection tracking

Info

Publication number: WO2017097352A1
Application number: PCT/EP2015/079117
Authority: WO
Inventors: Eshed GAL-OR; Eran Gampel; Ayal Baron
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2015-12-09
Filing date: 2015-12-09
Publication date: 2017-06-15
Also published as: CN108370325B; CN108370325A

Abstract

The present invention provides a system 100 for managing a network. The system 100 comprises at least one service network node 102 including at least one connection tracking module 103, which is configured to perform connection tracking on at least one packet belonging to a network service session. Further, the system 100 also comprises at least one external data storage or memory 104 configured to store connection tracking data obtained by the at least one connection tracking module 103. Finally, the system 100 comprises an application network node 106 including a common application layer configured to drive at least one application 108 based on the stored connection tracking data 105.

Description

MANAGING A NETWORK THROUGH CONNECTION TRACKING

TECHNICAL FIELD The present invention relates to a system for managing a network, a method for managing a network, and a computer program product for implementing said method when carried out on a computing device. In particular, the present invention suggests a collaboration of a distributed connection tracking mechanism and a common application layer. The common application layer employs distributed connection tracking data for running software applications and services.

BACKGROUND

In the world of datacenter network-related services and applications - such as security appliances, load balancers, traffic analyzers, etc. - applications are typically deployed as so- called disparate "silos". In such "silos" no information, for instance concerning network connection states, is shared between the applications. Accordingly, if in this "silo" model one or more network packets traverse several different applications, for instance, in a so-called "service chain" (e.g. a chain of the applications: Realtime Intrusion Detection and Prevention Anomaly Detection Network Optimization Load-Balancing), certain computations required to obtain and maintain network connection states of the packets may need to be repeated. Furthermore, each application in the service chains may need to parse each network packet that goes through it, in order to gather information that is necessary for its application logic. As a consequence, a performance/latency toll is inevitable.

In addition, information that is discovered in one application is not easily available to other applications without a specific integration between the different applications (e.g. applications from the same vendor, or applications using a well-supported and well-defined industry standard, such as NetFlow). Furthermore, the sharing of packet information between different applications is typically slow, as it is handled by the north-bound interfaces of the applications, which leads to a significant inherent latency that inhibits fast applications from taking this path. In order to address some of the problems, some applications in the state of the art are operated in the so-called "all-in-one" model. For this model a big "all-in-one" machine is created, which contains a shared state. In other words, some network connection states of network packets are shared between applications. In this way, multiple applications can reside and can be driven co- located in the same big "all-in-one" machine using the shared packet information.

However, the main disadvantages of this "all-in-one" model are:

• Vendor lock- in (i.e. all applications are pre-integrated into a closed system).

• Limited scalability (i.e. the scalability is based on the scale-up limitations of the product). · Limited features and a constrained product roadmap.

• Limited capability to integrate with applications of third parties.

• High costs of purchasing and licensing.

• High costs for high- availability and redundancy.

• High complexity when applications from different vendors are to be integrated.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to improve the state of the art, particularly the conventional application models described above. The present invention has the object to improve the efficiency and speed of driving various applications, either in parallel or in serial in a service chain. Thereby, the present invention seeks to avoid that each application needs to parse each network packet that goes through it. It should also be avoided that computations required for obtaining or maintaining network connection states of packets are unnecessarily repeated by different applications. Additionally, a fast and simple sharing of packet information between different applications is intended. 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 of the so-called "all-in-one" solutions. 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 proposes a distributed connection tracking mechanism to generate distributed connection tracking data, in order to gain a co-operative efficiency between service functions and applications. The present invention further proposes to utilize this distributed connection tracking data for the benefit of applications, such as Realtime Intrusion Detection and Prevention, Anomaly Detection, Network Optimization, Proactive Load Balancing and others. A first aspect of the present invention provides a system for managing a network, comprising at least one service network node including at least one connection tracking module configured to perform connection tracking on at least one packet belonging to a network service session, at least one external data storage or memory configured to store connection tracking data obtained by the at least one connection tracking module, and at least one application network node including at least one common application layer configured to drive at least one application based on the stored connection tracking data.

The connection tracking data may comprise a state of the at least one packet (e.g. a network connection state, like ESTABLISHED, RELATED etc.), forwarding information of the at least one packet, inspection data of the at least one packet, or similar information. In the system of the first aspect, the connection tracking data is written and read to/from the external data storage or memory by the at least one service network node. The connection tracking data may also be read and/or updated by the at least one application network node. The external storage or memory is preferably able to provide a read/write performance comparable to a local memory in a network node (e.g. by utilizing any of various technologies gaining popularity, like RAM cloud, DHT, SiPh, NVM, etc.). The external data storage or memory thus ensures that the reads and/or writes are fast enough to maintain the speed of the connection tracking logic (typically, in the order of microseconds).

The common application layer in the application network node enables simple and fast access to the stored connection tracking data by the one or more applications, either in an event-driven or in a scheduled manner. The at least one application that runs in the application network node can advantageously use the common application layer to execute its application logic based on the stored (and up-to date) connection tracking data. As a consequence, the speed and efficiency of the at least one application, and particularly the task of running various applications in parallel or in a service chain, is greatly improved.

The at least one application running on the application network node can read and update the connection tracking data in a highly consistent manner and nearly in real-time via the common application layer. Thus, it is not necessary that each application, for instance in a service chain, again parses each network packet that goes through it. An application can rather use the up-to date connection tracking data stored in the external storage or memory. As an example, a security application can check the network connections states in the network by operating on the stored and updated connection tracking data in the external storage or memory in real-time. This ensures that the security application can run fast enough and on the most recent data, so that a threat can be identified by it, before it can cause harm to the system.

Further, in the system of the first aspect is avoided that computations required for obtaining or maintaining network connection states of data packets are unnecessarily repeated by different applications. This advantageously affects the network path of the packet flow. Additionally, the common application layer in the application network node allows applications to perform traditional "inline" operations (e.g. load balancing, firewall) in an "offline" manner, which reduces many known complexities (e.g. single-point-of-failure, mechanical bypass mechanisms, packet congestion, etc.). In a first implementation form of the system according to the first aspect, the external data storage or memory is configured to share the stored connection tracking data across all service and application network nodes.

The external data storage or memory, and the sharing of the connection tracking data across all network nodes, greatly improves the scalability of the system. Furthermore, since the connection tracking data of all packets can be shared among all network nodes of the system, it is possible that once a network service session has been started in a specific instance of the network service, e.g. on a certain service network node, consecutive packets of the same network service session must not necessarily be routed to the same instance, but can also be routed to other instances, e.g. to instances on other network nodes. Moreover, applications running on an application network node can efficiently utilize the shared connection tracking data for their application logic. 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 at least one common application layer comprises a registration application programming interface, API, which is configured to allow the at least one application to specify a manner of interaction with the at least one common application layer.

As a consequence, the applications are provided with great flexibility of interaction with the common application layer and usage of the stored connection tracking data. The applications can, for instance, choose, whether to interact with the external data storage or memory via the common application layer or not. 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 at least one common application layer comprises a scheduler, which is configured to trigger a time-based interaction of the at least one application with the at least one common application layer.

Accordingly, the common application layer is able to provide a "time-based" interaction model for the at least one application. Thus, simple and fast access to the stored connection tracking data in a scheduled manner is enabled.

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 at least one common application layer comprises an event handler, which is configured to trigger an event-based interaction of the at least one application with the at least one common application layer.

Accordingly, the common application layer is able to provide an "event-based" interaction model for the at least one application. Thus, simple and fast access to the stored connection tracking data in an event-driven manner is provided.

In a fifth implementation form of the system according to any one of the second to fourth implementation form of the first aspect, the at least one common application layer comprises an engine, which is configured to implement the interaction of the at least one application with the at least one common application layer.

The engine simplifies the handling and implementation of the different possible interaction models, by implementing any registered interaction with the at least one application. In a sixth implementation form of the system according to the fifth implementation form of the first aspect, the engine is configured to register and/or activate the at least one application, when a predetermined type of event is received by or occurs in the system.

For example, via the "event-based" interaction model implemented by the engine, an "Intrusion Prevention Service" can insert itself into a service chain of "SSH" connections, and can thus register to all new connections to a TCP port 22 on a perimeter firewall.

In a seventh implementation form of the system according to the fifth or sixth implementation form of the first aspect, the engine is configured to register and/or activate the at least one application upon a predetermined time period. For example, via the "time-based" interaction model implemented by the engine, an application may register to be activated by the scheduler once an hour, once a day etc. An example for such an application is an "Intrusion Detection Service", which parses all traffic information over e.g. a past hour. The parsing can be carried out in real-time. Another example is a "Report Generator" that accumulates different traffic and runs every other day. 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, each service and application network node is configured to access and update the connection tracking data stored in the at least one external data storage or memory.

Thus, the shared connection tracking data can be kept updated at all times, so that each network node of the system has access, for instance, to all up-to date network connection states of packets. Thereby, the freedom to route consecutive packets belonging to the same network service session as a previous packet to any desired instance on any service network node of the system is achieved. Moreover, each application can run based on the most recent connection tracking data, and synergies between different applications with respect to obtaining or maintaining network connection states are achieved.

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 at least one external data storage or memory is configured to store connection metadata, and the common application layer is configured to drive the at least one application based on the stored connection metadata. In a tenth implementation form of the system according to ninth implementation form of the first aspect, the external data storage or memory is configured to share the stored connection metadata across all service and application network nodes.

On the one hand side, sharing the connection metadata among the service network nodes allows an even more efficient routing of multiple packets of a network service session through different instances, for example, on different service network nodes. Thus, the scalability of the system is further supported. On the other hand side, sharing the connection metadata among the application network nodes allows applications to be driven even more efficiently and with up- to date information, e.g. information obtained by applications located earlier in a service chain of applications.

In an eleventh implementation form of the system according to the ninth or tenth implementation form of the first aspect, each service network node is configured to add connection metadata, which is aggregated in the service network node by processing the a least one packet, to the connection metadata stored in the at least one external data storage or memory.

Accordingly, the connection metadata stored in the external storage or memory may be connection metadata obtained in each service network node. Advantageously, identical connection metadata obtained likewise in different service network nodes must be stored only once, since it is shared across all service network nodes. Also each application network node may be configured to add or update metadata to the stored connection metadata. Thus, each application and service network node has access to the most recent connection metadata from each other application or service network node.

In a twelfth implementation form of the system according to the first aspect as such or according to any previous implementation form of the first aspect, each service network node is configured to run at least an instance of at least one network service session.

Accordingly, a network service session can run in one or more instances on one or more service network nodes in parallel. This allows increasing the system performance, for instance, by load balancing. Further, scalability of the system is improved.

A second aspect of the present invention provides a method for managing a network, comprising the steps of performing connection tracking in at least one service network node on at least one packet belonging to a network service session, storing obtained connection tracking data in at least one external data storage or memory outside of the at least one service network node, and driving at least one application in at least one application network node based on the stored connection tracking data.

In a first implementation form of the method according to the second aspect, the external data storage or memory shares the stored connection tracking data across all service and application network nodes.

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 at least one common application layer comprises a registration application programming interface, API, which allows the at least one application to specify a manner of interaction with the at least one common application layer.

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 at least one common application layer comprises a scheduler, which triggers a time-based interaction of the at least one application with the at least one common application layer.

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 at least one common application layer comprises an event handler, which triggers an event-based interaction of the at least one application with the at least one common application layer. In a fifth implementation form of the method according to any of the second to fourth implementation forms of the second aspect, the at least one common application layer comprises an engine, which implements the interaction of the at least one application with the at least one common application layer.

In a sixth implementation form of the method according to the fifth implementation form of the second aspect, the engine registers and/or activates the at least one application, when a predetermined type of event is received by or occurs in the system.

In a seventh implementation form of the method according to the fifth or sixth implementation form of the second aspect, the engine registers and/or activates the at least one application upon a predetermined time period. 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, each service and application network node accesses and updates the connection tracking data stored in the at least one external data storage or memory. 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 at least one external data storage or memory stores connection metadata, and the common application layer drives the at least one application based on the stored connection metadata.

In a tenth implementation form of the method according to ninth implementation form of the second aspect, the external data storage or memory shares the stored connection metadata across all service and application network nodes.

In an eleventh implementation form of the method according to the ninth or tenth implementation form of the second aspect, each service network node adds connection metadata, which is aggregated in the service network node by processing the a least one packet, to the connection metadata stored in the at least one external data storage or memory.

In a twelfth implementation form of the method according to the second aspect as such or according to any previous implementation form of the first aspect, each service network node runs at least an instance of at least one network service session.

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 managing a network 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 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 an advanced system according to an embodiment of the present invention.

Fig. 3 shows details of a common application layer in a system according to an embodiment of the present invention. Fig. 4 shows a method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows a basic system 100 according to an embodiment of the present invention. The system 100 is used for managing a network, and comprises at least one service network node 102, wherein preferably each service network node 102 is configured to run at least an instance of at least one network service 101 session, at least one external data storage or memory 104, and at least one application network node 106, wherein preferably each application network node 106 is configured to drive at least one application 108. The at least one network service 101 may be one or more of e.g. a Firewall, NAT, a Load-Balancer, a Hypervisor, or the like. The at least one application 108 may be Realtime Intrusion Detection and Prevention, Anomaly Detection, Network Optimization Proactive Load-Balancing, or the like.

The at least one service network node 102 includes at least one connection tracking module 103, which is configured to perform connection tracking on at least one packet belonging to a network service 101 session. Thereby, connection tracking data is obtained, for instance a network connection state or forwarding information of the at least one packet.

The at least one external data storage or memory 104 is configured to receive from the at least one service network node 102 and store the connection tracking data obtained by the at least one connection tracking module 103. Likewise, it is configured to send the stored connection tracking data 105 to the at least one service network node 102 and to the at least one application network node 106, and thereby share it across all network nodes 102, 106 of the system 100. The at least one data storage or memory 104 is preferably a distributed hash table, a Random Access Memory cloud, or a distributed cache. The at least one application network node 106 includes at least one common application layer 107, which is configured to drive the at least one application 108. In particular, the common application layer 107 is configured to obtain the stored connection tracking data 105, so as to drive the at least one application 108 based on said stored connection tracking data 105.

Fig. 2 shows an advanced implementation of the basic system shown in Fig. 1. In this implementation, the system 100 includes two service network nodes 102 (indicated with Node A, and Node C), one application network node 106 (indicated with Node B) and one external data storage or memory 104 (indicated with External Data Storage). The service network nodes 102 are preferably each operated by a Linux-based operation system, which includes a Kernel module 204. The Kernel module 204 includes preferably the at least one connection tracking module 103. The Kernel 204 may further include a network processor 203 acting, for instance, as a forwarding element for packets, and a local (i.e. an internal) data storage or memory 200, which is configured to locally store the connection tracking data obtained by the at least one connection tracking module 103. The local data storage or memory 200 thus acts as a cache, and may be optionally implemented to improve the system performance. Furthermore, a software hook 201 may be implemented in each connection tracking module 103, preferably in an API thereof, and is configured to intercept, write and/or read connection tracking data from and/or to the external data storage or memory 104, instead of (or in addition to) the local connection tracking data storage or memory 200.

The external data storage or memory 104 is preferably a high-speed low-latency distributed memory (such as a Distributed Memory Data Base or a similar technology), to which the connection tracking data will be written, and from which the connection tracking data will be read, in order to share it across all network nodes 102. Thereby, a distributed connection state can be provided across all instances of the at least one network service 101 session running on at least one service network node 102.

In addition to the connection tracking data, the external data storage or memory 104 of the system 100 shown in Fig. 2 may also store connection metadata 202 (also referred to as extended metadata), and can share the stored connection metadata 202 across all network nodes 102, 106. That is, connection metadata that is continuously aggregated and added in each service network node 102 of the system 100 processing a packet belonging to a network service 101 can be written to and read from the external data storage or memory 104. Also the application network node 106 may write to and read from the external data storage or memory 104 connection metadata. The connection metadata may also be stored in one or more internal data storages or memories 200 on the service network nodes 102.

It is also possible to make available an auxiliary network, preferably a separate physical highspeed, low-latency network, in order to support all connection tracking data reads and/or writes to/from the external data storage or memory 104. Thereby - as is indicated in Fig. 2 - the connection tracking data, and optionally also the connection metadata, may be readily accessible as e.g. a Global Connection Tracking 105 repository and an Extended Metadata 202 repository, respectively.

The application network node 106 (preferably a compute node) of Fig. 2 is shown to run a plurality of applications 108 (indicated with App k, App j) with its at least one common application layer 107. The applications 108 may have registered on the application network node 106 at system initialization time. The common application layer 107 can particularly drive the plurality of applications 108 based on the stored connection tracking data 105 and optionally also based on the stored connection metadata 202. Fig. 3 shows details of the common application layer 107 in the application network node 106. The common application layer 107 comprises preferably a registration application programming interface (registration API) 301, a scheduler 302, an event handler 303, and an engine 304. Further, the common application layer 107 comprises preferably a data access API 305. The registration API 301 is configured to allow one or more applications 108 to register with the common application layer 107, and allow them to specify a manner of interaction with the common application layer 107. For example, the applications 108 may choose a "time-based" interaction, an "event-based" interaction or a flexible interaction according to their need.

The interactions of the one or more applications 108 with the at least one common application layer may in some cases be triggered by the common application layer 107. To this end, the scheduler 302 is configured to trigger a "time -based" interaction of an application 108 with the common application layer 107, and the event handler 303 is configured to trigger an "event- based" interaction of an application 108 with the common application layer 107.

The engine 304 may receive a trigger signal from the scheduler 302 and/or the event handler 303, and is then configured to implement - based on the received trigger signal and via a callback to an application 108 - the interaction of the common application layer 107 and the application 108. That means particularly, the engine 304 may register and/or activate the application 108, when a predetermined type of event is received by or occurs in the system 100, or may register and/or activate the application 108 upon a predetermined time period. The engine 304 is further configured to provide the scheduler 302 with a schedule, i.e. to set the scheduler 302 to output its trigger signal, for instance, every minute, hour, day etc.

The common application layer 107 further has access to the external data storage or memory 104, particularly to the stored connection tracking data 105 and optionally to the stored connection metadata 202. The external data storage or memory 104 may provide, i.e. may share, the stored information with the common application layer 107 in the application network node 106 via a data flow. Accordingly, the common application layer 107 can drive the one or more applications 108 based on the stored connection tracking data 105 and/or the stored connection metadata 202. Consequently, an application 108 can carry out its function with full knowledge of the up-to date network connection states and/or up-to date metadata, and can thus react efficiently to changes or occurrences in these network connections states in real-time. The data access API 305 is configured to allow services and applications 108 to interact with the external data storage or memory 104 directly or indirectly, in order to query connection tracking data 105 and/or connection metadata 202, or in order to update said data 105 and/or 202. In particular, the data access API 305 of the common application layer 107 is on the one and side configured to receive a query and/or update request for connection tracking data 105 and/or connection metadata 202 from the one or more applications 108, and to forward these requests to the external data storage or memory 104. On the other hand side, the data access API 305 may itself be configured to query information concerning connection tracking data 105 and/or connection metadata 202 from the external data storage or memory 105, and to update the stored connection tracking data 105 and/or the stored connection metadata 202 in the external data storage or memory 104, for instance, after or during an interaction with an application 108. In a possible implementation of the system 100 having the common application layer 107 shown in figs. 1 and 3, an application 108 may register to be activated by the event handler 303 and engine 304, when a type of event was received in the system 100 (i.e. triggered by an event), e.g. a new connection was created in "Service n". An example for such an application 108 is an "Intrusion Prevention Service" that inserts itself into the service chain of all "SSH" connections, and therefore registers to all new connections to TCP port 22 on the perimeter firewall.

In another possible implementation, an application 108 may register to be activated by the scheduler 302 and engine 304 upon a given time period, e.g. once an hour, once a day, etc. An example for such an application 108 is an "Intrusion Detection Service" that parses all traffic information over the past hour. Another example for such an application 108 is a report generator that accumulates various traffics and runs every day.

Fig. 4 shows a method 400 for managing a network according to an embodiment of the present invention. In a first step 402 of the method 400, connection tracking in at least one service network node 102 is performed on at least one packet 401 arriving at said at least one service network node 102, the packet 401 belonging to a network service 101 session. In a second step 403, the thereby obtained connection tracking data is stored in at least one external data storage or memory 104, which is located outside of the at least one service network node 102. In a third step 404, the connection tracking data 105 stored in the at least one external data storage or memory 104 is used by a common application layer 107 provided in at least one application network node 106, in order to drive at least one application 108 based on the stored connection tracking data 105.

In summary, by the proposed system 100 and method 400, the present invention provides a platform for more efficiently driving various applications 108 in a network. Advantageously, these applications 108 can access all current connection states in the network - represented by the stored connection tracking data 105 - in real-time, and thereby either as desired, in an event- driven manner, or in a scheduled manner. Accordingly, the applications 108 can run and react faster and more efficiently, for instance, to occurrences in the system 100, or to changes in the network connection states.

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 fulfil 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. System (100) for managing a network, comprising at least one service network node (102) including at least one connection tracking module (103) configured to perform connection tracking on at least one packet belonging to a network service (101) session, at least one external data storage or memory (104) configured to store connection tracking data (105) obtained by the at least one connection tracking module (103), and at least one application network node (106) including at least one common application layer (107) configured to drive at least one application (108) based on the stored connection tracking data (105).

2. System (100) according to claim 1, wherein the external data storage or memory (104) is configured to share the stored connection tracking data (105) across all service and application network nodes (102, 106).

3. System (100) according to one of the claims 1 and 2, wherein the at least one common application layer (107) comprises a registration application programming interface, API, (301), which is configured to allow the at least one application (108) to specify a manner of interaction with the at least one common application layer (107).

4. System (100) according to one of the claims 1 to 3, wherein the at least one common application layer (107) comprises a scheduler (302), which is configured to trigger a time -based interaction of the at least one application (108) with the at least one common application layer (107).

5. System (100) according to one of the claims 1 to 4, wherein the at least one common application layer (107) comprises an event handler (303), which is configured to trigger an event-based interaction of the at least one application (108) with the at least one common application layer (107).

6. System (100) according to one of the claims 3 to 5, wherein the at least one common application layer (107) comprises an engine (304), which is configured to implement the interaction of the at least one application (108) with the at least one common application layer (107).

7. System (100) according to claim 6, wherein the engine (304) is configured to register and/or activate the at least one application (108), when a predetermined type of event is received by or occurs in the system (100).

8. System (100) according to one of the claims 6 and 7, wherein the engine (304) is configured to register and/or activate the at least one application (108) upon a predetermined time period.

9. System (100) according to one of the claims 1 to 8, wherein each service and application network node (102, 106) is configured to access and update the connection tracking data (105) stored in the at least one external data storage or memory (104).

10. System (100) according to one of the claims 1 to 9, wherein the at least one external data storage or memory (104) is configured to store connection metadata (202), and the common application layer (107) is configured to drive the at least one application (108) based on the stored connection metadata (202).

11. System (100) according to claim 10, wherein the external data storage or memory (104) is configured to share the stored connection metadata (202) across all service and application network nodes (102, 106).

12. System (100) according to one of the claims 10 and 11, wherein each service network node (102) is configured to add connection metadata, which is aggregated in the service network node (102) by processing the a least one packet, to the connection metadata (202) stored in the at least one external data storage or memory (104).

13. System (100) according to one of the claims 1 to 12, wherein each service network node (102) is configured to run at least an instance of at least one network service (101) session.

14. Method (400) for managing a network, comprising the steps of performing (402) connection tracking in at least one service network node (102) on at least one packet (401) belonging to a network service (101) session, storing (403) obtained connection tracking data (105) in at least one external data storage or memory (104) outside of the at least one service network node (102), and driving (404) at least one application (108) in at least one application network node (106) based on the stored connection tracking data (105).

15. Computer program product for implementing, when carried out on a computing device, a method (400) for managing a network according to claim 14.