COMMUNICATION TRAFFIC MONITORING PROTOCOL

Abstract

A first network probe is associated with a first router and the first endpoint of that router, and a second network probe is associated with a second router and the second endpoint of that router. The first network probe periodically injects flag packets in parallel with the traffic of a communication tunnel between the first and second endpoints. Each flag packet includes a timestamp indicating the time of its injection. Information regarding traffic rate variation in the communication tunnel is collected. This rate variation is measured by the difference between the timestamps contained in the flag packets and the timestamps of the flag packets' capture time by the second network probe.Potential congestion situations affecting the communication tunnel are assessed based on the information collected. Figure to be published with the abbreviation: Fig. 6.

Description

Title of the invention: COMMUNICATION TRAFFIC MONITORING PROTOCOL Technical field

[0001] The present invention relates to the field of network probes for monitoring traffic passing through a communication tunnel, and thus detecting and evaluating congestion states in communication networks, for example of the WAN type (Wide Area Network). STATE OF PRIOR ART

[0002] Communication networks are used to offer a wide variety of services, such as the exchange of voice communications, typically so-called VoIP services ("Voice over IP" in English), the exchange of audiovisual communications, the broadcasting of multimedia programs, or even access to data, typically access to Web services. These services have different needs in terms of transmission latency in communication networks, and have different priorities.

[0003] The communication links on which communication networks are based are based on physical transmission technologies which can be very diverse. Each of these technologies leads to different properties of the transmission channel used in terms of capacities, i.e. available bandwidth, error rate, or variability of this available bandwidth.

[0004] In order to adequately manage the admission of services taking into account these different transmission channel properties or in order to construct a predictive model of the transmission channel, network probes are used to analyze the traffic passing through these communication networks, and in particular in communication tunnels established between routers of these communication networks.

[0005] One difficulty lies in the fine evaluation of the congestion states of these communication networks.

[0006] It is then desirable to overcome at least this drawback of the prior art, and to do so in a simple, effective and inexpensive manner. Statement of the invention

[0007] To this end, a method is proposed implemented in a communication system comprising a plurality of routers, a first network probe being associated with a first router of said plurality of routers and with a first termination point of the first router, a second network probe being associated with a second router of said plurality of routers and with a second termination point of the first router, the method comprising the following steps in the context of monitoring traffic in a communication tunnel between the first endpoint and the second endpoint: periodically injecting, by the first probe, flag packets in parallel with the traffic of the communication tunnel, each flag packet including timestamp information expressing a time reference for injection of said flag packet; collecting information relating to a variation in traffic timing in the communication tunnel, the variation in timing being measured using a difference between the timestamp information contained in the flag packets and timestamp information of the instant of capture of said flag packets by the second probe; evaluating possible congestion situations experienced by the communication tunnel based on said collected information.Thus, the difference in the timing of receiving flag packets compared to their timing of sending makes it possible to estimate the variation in timing in the communication tunnel which takes the same path as the flag packets, and thus to finely evaluate the congestion situations which may arise.

[0008] In a particular embodiment, the method comprises the following step: calculating a possible loss of data volume in the communication tunnel, by comparison between a count of data volume at the output of the communication tunnel between successive flag packets, detected by the second probe, and a count of data volume at the input of the communication tunnel between successive flag packets, detected by the first probe.

[0009] In a particular embodiment, the flag packets are UDP type packets sent on a port dedicated to said flag packets. Thus, the flag packets can be easily captured by network probes.

[0010] In a particular embodiment, the flag packets are injected for each type of service among a plurality of types of service transported by the communication tunnel. Thus, congestion situations can be evaluated for each type of service, therefore more finely.

[0011] In a particular embodiment, the flag packets are injected into a user plane upstream of the first termination point relative to the communication tunnel.

[0012] In a particular embodiment, to collect information relating to a variation in the timing of data flows in the communication tunnel, at least the second network probe comprises at least one measurement table for storing a history of samplings of flag packets captured at the output of the communication tunnel, each entry of the measurement table corresponding to a sample comprising: a timestamp information field as contained in the flag packet corresponding to the sample in question; a timestamp information field marking the instant at which the flag packet corresponding to the sample in question was captured; a sequence number field as contained in the flag packet corresponding to the sample in question; and a data count field transiting in the communication tunnel between the flag packet corresponding to the sample in question and the flag packet corresponding to the next sample in the measurement table. Thus, the sampling history is easily constructed by the second probe to allow the evaluation of congestion situations.

[0013] In a particular embodiment, the first probe transmits to the second probe a request requiring the transmission in response of information derived by calculations of a sampling history of the flag packets received by the second probe, the request involving an interval of sequence numbers to be considered, the calculations being intended to evaluate possible congestion situations and including: a minimum transit latency of the flag packets of said interval of sequence numbers; a maximum transit latency of the flag packets of said interval of sequence numbers; an average transit latency of the flag packets of said interval of sequence numbers; a minimum jitter experienced by the flag packets of said interval of sequence numbers; a maximum jitter experienced by the flag packets of said interval of sequence numbers; an average jitter experienced by said interval of sequence numbers;a data transit volume in the communication tunnel over said sequence number interval. Thus, the bandwidth consumption for transmitting information by the second probe to the first probe making it possible to assess congestion situations is reduced.;

[0014] In a particular embodiment, the first probe transmits to the second probe a request requiring the transmission in response of all or part of the sampling history of the flag packets received by the second probe, the first probe then performing calculations intended to evaluate possible congestion situations and including: a minimum transit latency of the flag packets of said sequence number interval; a maximum transit latency of the flag packets of said sequence number interval; an average transit latency of the flag packets of said sequence number interval; a minimum jitter experienced by the flag packets of said sequence number interval; a maximum jitter experienced by the flag packets of said sequence number interval; an average jitter experienced by said sequence number interval; a data transit volume in the communication tunnel over said sequence number interval..

[0015] In a particular embodiment, the first network probe comprises at least one other measurement table for storing a history of samplings of flag packets captured at the input of the communication tunnel, each entry of this other measurement table corresponding to a sample comprising: an information field timestamp as contained in the flag packet corresponding to the sample in question; a timestamp information field marking the instant at which the flag packet corresponding to the sample in question was captured; a sequence number field as contained in the flag packet corresponding to the sample in question; and a data count field transiting in the communication tunnel between the flag packet corresponding to the sample in question and the flag packet corresponding to the next sample in the measurement table. Thus, the sampling history is easily constructed by the first probe to allow the evaluation of congestion situations.

[0016] In a particular embodiment, the first network probe calculates additional latency information and additional jitter information, which are linked to the quality of service of the first router, by comparing the timestamp information contained in the injected flag packets and the capture timestamp information of the flag packets captured by said first network probe. Thus, the involvement of the router in question in congestion situations can be easily evaluated.

[0017] In a particular embodiment, the first probe further estimates a possible loss of data volume which is linked to the quality of service of the first router, from detection of losses of flag packets injected by the first probe. Thus, the evaluation of the involvement of the router in question in congestion situations is completed.

[0018] There is also provided a communication system comprising network probes and a plurality of routers, a first network probe being associated with a first router of said plurality of routers and with a first termination point of the first router, a second network probe being associated with a second router of said plurality of routers and with a second termination point of the first router, the communication system comprising electronic circuitry configured to carry out the following steps in the context of monitoring traffic in a communication tunnel between the first termination point and the second termination point: periodically injecting, by the first probe, flag packets in parallel with the traffic of the communication tunnel, each flag packet including time stamp information expressing a time reference for injection of said flag packet;collecting information relating to a variation in traffic timing in the communication tunnel, the variation in timing being measured using a difference between the timestamp information contained in the flag packets and timestamp information of the instant of capture of said flag packets by the second probe; evaluating possible congestion situations experienced by the communication tunnel based on said collected information.; Brief description of the drawings

[0019] The following description of at least one embodiment is set forth in relation to the accompanying drawings, among which:

[0020] [Fig.lA] schematically illustrates a communication system;

[0021] [Fig.lB] schematically illustrates a network probe arrangement;

[0022] [Fig.lC] schematically illustrates a complementary network probe arrangement;

[0023] [Fig.2] schematically illustrates a connection of network probes with an orchestrator;

[0024] [Fig.3] schematically illustrates an example of hardware architecture allowing the implementation of network probes of the communication system;

[0025] [Fig.4] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel upstream of said communication tunnel;

[0026] [Fig.5] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel downstream of said communication tunnel;

[0027] [Fig.6] schematically illustrates a variation in data flow timing in a communication tunnel;

[0028] [Fig.7] schematically illustrates a flowchart for creating and updating one or more measurement tables storing information representative of the variation in the timing of the data flow of [Fig.6];

[0029] [Fig.8] schematically illustrates an example of a measurement table structure;

[0030] [Fig.9] schematically illustrates a network probe collaboration flowchart to assess a congestion situation in a communication tunnel, in a first embodiment; and

[0031] [Fig. 10] schematically illustrates a network probe collaboration flowchart for assessing a congestion situation in a communication tunnel, in a second embodiment.

[0032] DETAILED DESCRIPTION OF EMBODIMENTS

[0033] [Fig.lA] schematically illustrates a communication system.

[0034] The communication system comprises a plurality of routers 110. Three routers RI to R3 are shown, for illustration purposes, in [Fig. 1 A]. The routers 110 are interconnected by at least one communication network 100a on which said routers 110 establish communication tunnels. Thus, the routers 110 comprise at least one communication tunnel end-point 120. Each end-point 120 may relate to one or more communication tunnels.

[0035] Each communication network 100a can be of a varied nature, whether wired such as Ethernet links, or optical fiber, or radio such as satellite links. Two communication networks 100a WAN1 and WAN2, of the WAN type (“Wide Area Network” in English), are shown for illustration purposes in [Fig.1A].

[0036] Communication tunnels are for example implemented using the GRE protocol (Generic Routing Encapsulation), or the mGRE protocol (Multipoint Generic Routing Encapsulation), or the IPSec family of standards (Internet Protocol Security). Other tunneling protocols can be used as a variant.

[0037] Preferably, the communications tunnels are secured by encryption, so that the data encapsulated in the encapsulation protocol of the communications tunnel cannot be deciphered by a device which would be located between the two termination points 120 of the communications tunnel.

[0038] For example, the communication tunnels are used to connect other communication networks 100b via said routers 110. As illustrated in [Fig. 1A], the routers 110 and the communication tunnels make it possible to interconnect local area networks (LANs), such as WLANs (Wireless Local Area Networks), for example of the IEEE 802.11 standard family. In a particular embodiment, the communication system thus makes it possible to securely connect terminals present on local area networks (LAN1, LAN2, LAN3) 100b (called red networks) via the wide area network (WAN1) 100a (called black network). Thus, illustratively in [Fig.lA], a first communication tunnel is established on the WAN1 network between an endpoint El of the router RI and an endpoint E3 of the router R2, and a second communication tunnel is established on the WAN1 network between the endpoint El and an endpoint E4 of the router R3. A third communication tunnel is established on the WAN1 network between the endpoint E3 of the router R2 and the endpoint E4 of the router R3. A fourth communication tunnel is established on the WAN2 network between an endpoint E2 of the router RI and an endpoint 120 of another router not shown.

[0039] The communication system is equipped with network probes. The network probes are arranged and configured to perform measurements of the flow rate of data entering the communication tunnels and of data leaving the communication tunnels, i.e. at the termination points 120 of the communication tunnels, so as to be able to detect and evaluate congestion situations in the communication network(s) 100a.

[0040] The throughput measurements are measurements, over time periods delimited by flag packets, of volumes of data encapsulated in the protocol of the communication tunnels. The network probes may be included in the routers 110 or connected thereto, provided that said network probes have access to the data plane of the routers 110 in order to be able to set up an inter-probe communication protocol and to be able to inject flag packets in order to time the data throughput measurements in the communication tunnels, and to capture the volume of packets transmitted in the communication tunnels and the flag packets relating thereto.

[0041] The inter-probe communication protocol allows the network probes of the termination points 120 of the same communication tunnel to send each other information relating to said measurements in order to evaluate congestion states on the communication network(s) 100a.

[0042] The arrangement presented above ensures that the inter-probe communications protocol takes the same path as the packets of the communication tunnel supervised by the network probes in question.

[0043] A said network probe is thus associated with each termination point 120 of the communication tunnels to be monitored in terms of encapsulated data rate. Note that communication tunnels may exist in the communication system while no network probe is set up at their termination points 120.

[0044] In a particular embodiment, the network probes are arranged as schematically illustrated in [Fig.lB].

[0045] [Fig. 1B] thus presents a modular network probe architecture comprising a network probe manager 160, an injector 150, an application module 165, and a capture module 155.

[0046] The capture module 155 includes a filtering module for recovering, via an interface module of the router with which said network probe is associated, data packets relating to communication tunnels. Thus, the filtering module makes it possible, for example, to obtain a copy of any GRE, mGRE or IPSec type data packet intended for or originating from the termination point 120 with which said network probe is associated. In addition, the filtering module makes it possible to obtain a copy of any flag packet (as described below) included in the traffic of the communication tunnel monitored by the network probe in question. The capture module 155 preferably includes two sub-modules: a sub-module for capturing traffic entering the communication tunnel and a sub-module for capturing traffic leaving the communication tunnel, the communication tunnel being bidirectional.We can thus see the capture module 155 as two specialized capture points per ter- point. mining 120.

[0047] The injector 150 is adapted and configured to inject flag packets in parallel with the traffic of the supervised communication tunnel (outgoing traffic), that is to say when the network probe in question is associated with the termination point 120 at the input of the communication tunnel. The flag packets are therefore not encapsulated in the protocol of the communication tunnel, but follow the same path. Indeed, if the protocol of the communication tunnel uses data encryption, the flag packets could then not be detected on reception. The network probe is configured and adapted so that the network injector 150 injects the flag packets into a user plane 140 upstream of the termination point 120 relative to the supervised communication tunnel, but without the flag packets transiting through the communication tunnel in question.The user plane 140 is the data path in the router 110 with which said network probe is associated and through which the packets originating from the communication network 100b which are transmitted in the communication tunnel in question by the local termination point 120 pass. Alternatively, when the communication tunnel does not employ encryption, the flag packets may be part of the traffic transiting in the communication tunnel and be seen by the local termination point 120 as originating from the communication network 100b upstream of the local termination point 120 with respect to the monitored communication tunnel. In another variant where the traffic in the communication tunnel may be encrypted, the injector 150 injects the flag packets between the termination point 120 at the inlet of the communication tunnel and the local capture point of the network probe in question.In all the cases mentioned above, this implies that the flag packets are perceptible and detectable by the local capture point of the network probe in question.

[0048] It should be noted that part of the content of the flag packets, not necessary for their routing, may be encrypted between the network probes involved. However, the encryption applied is controlled by the network probes in question and is independent of the encryption used by the communication tunnel with which the flag packets in question are associated.

[0049] The injector 150 is configured to generate and transmit the flag packets periodically, according to a period of time defined by the network probe manager 160 or by pre-configuration. The rate of the injected flag packets can be modified or adjusted by the network probe manager 160 over time.

[0050] In a particular embodiment, the flag packets are UDP (User Datagram Protocol) packets sent on a port dedicated to said flag packets. Preferably, such flag packets are injected for each type of service transported by the supervised communication tunnel. For example, packets flags are injected by the injector 150 for each DSCP (Differentiated Services Code Point) field value of the packets in the communication tunnel.

[0051] Each flag packet includes timestamp information expressing a time reference for injection of said flag packet, as well as a sequence identifier (Seq).

[0052] For example, each flag packet includes a routing header (e.g., IP type) including a source address field indicating the address of the local network probe, a destination address field indicating the address of the remote network probe, and a service type field (e.g., DSCP type) indicating the type of service in which the flag packet in question is registered. The routing header has, for example, a size of 20 to 40 bytes. In this example, each flag packet then includes a transport header (e.g., UDP type) indicating a destination port, and possibly a source port, dedicated to flag packets (and known to all the network probes of the communication system). The transport header has, for example, a size of 8 bytes. Still in this example, each flag packet then includes a packet type field, for example having a size of 1 byte and a value equal to 0.Still in this example, each flag packet then comprises a sequence identifier field which indicates a (cyclic) order number of said flag packet in a succession of transmissions of said flag packets by the injector 150, as well as a timestamp field having a size of 8 bytes expressing a time reference of transmission of said flag packet by the injector 150 with millisecond precision. The flag packets thus constructed allow easy filtering upon reception by the network probe on the other side of the supervised communication tunnel.

[0053] The network probe manager 160 is configured and arranged to store metrics linked to measurements carried out using the capture module 155, coordinate the establishment and progress of inter-probe communications for a given communication tunnel, and consolidate the stored metrics in order to supply the application module 165 with communication tunnel monitoring information.

[0054] The network probe manager 160 implements an inter-probe communication protocol, thus enabling said network probe to communicate with one or more other said network probes as part of the supervision of one or more respective said communication tunnels. A UDP port dedicated to the inter-probe communication protocol is preferably used for this purpose. Such an inter-probe protocol notably enables sharing of measurement information carried out by said network probes or calculation information resulting therefrom.

[0055] In a particular embodiment, each network probe has an address, for communicating in the communication network(s) 100a, which is predefined by relative to the address of the communication tunnel endpoint 120 with which said network probe is associated. This makes it possible to automatically put the relevant network probes into communication when a new communication tunnel is detected (eg, established). This also makes it possible to automatically configure the filtering of flag packets transmitted by the injector 150, by the remote network probe associated with the endpoint 120 on the other side of the monitored communication tunnel.

[0056] More precisely, the address of the network probe is determined by applying a bijective translation function with respect to the address of the termination point 120 with which said network probe is associated.

[0057] In a particular embodiment, the address of said network probe is obtained by applying a predefined conversion rule (“mapping” in English) from the address of the termination point 120 with which said network probe is associated.

[0058] In a particular embodiment, the address of said network probe is obtained by applying a predefined offset (positive or negative) relative to the address of the termination point 120 with which said network probe is associated.

[0059] In a particular embodiment, the address of said network probe is obtained by adding one (i.e., a unit) to the address of the termination point 120 with which said network probe is associated.

[0060] The same mechanism applies for defining the addresses of the other network probes of the communication system. Thus, the address of a remote network probe (i.e., on the other side of a supervised communication tunnel) is determined by applying the bijective translation function with respect to the address of the termination point 120 with which said remote network probe is associated.

[0061] In an alternative embodiment, the network probes have addresses independent of the addresses of the communication tunnel termination points 120. Optionally, the injectors 150 have their own addresses. Upon discovery of a communication tunnel, the network probe in question notifies its addressing plan to the remote network probe. To do this, a message is sent on a dedicated port (for example, a dedicated UDP port) for inter-probe messages, with a dedicated message identifier. The message in question indicates which termination points 120 are concerned by the discovered communication tunnel. Since the remote probe is configured to receive (listen) to the messages received on this dedicated port, this remote probe can recognize the communication tunnel (the termination point 120) which concerns it, and the addressing plan used on the other side of the communication tunnel becomes known to it.This remote probe can in turn transmit its own addressing plan in the same manner. In a particular embodiment, the flag packets include information indicating which endpoints 120 are concerned by the communication tunnel with which said flag packets are associated, as well as the plan. addressing mentioned above.

[0062] The messages exchanged within the framework of the inter-probe protocol are preferably of a higher priority traffic type. For example, the messages exchanged within the framework of the inter-probe protocol have a higher priority DSCP field value than the packets which are encapsulated in the supervised communication tunnels (i.e., higher priority than the communication packets between the communication networks 100b). In a particular embodiment, the messages exchanged within the framework of the inter-probe protocol have a DSCP field value which corresponds to a maximum possible priority. This makes it possible to limit the impact of congestion situations on the transit of said messages exchanged within the framework of the inter-probe protocol and thus allow better reactivity, if necessary, to congestion situations.

[0063] The application module 165 is responsible for collecting information relating to a variation in the timing of data flows in the communication tunnel supervised by said network probe, the variation in timing being measured using a variation in the difference between the timestamp information contained in the flag packets and timestamp information of the instant of capture of said flag packets. The application module 165 can perform calculations on said measurements in order to detect and evaluate congestion situations, taking into account measurements also carried out by an equivalent application module in a remote network probe responsible for supervising the communication tunnel at its other termination point.

[0064] For example, the application module 165 may be responsible for instructing the local router to modify data transmission profiles in the communication network(s) 100a so as to take into account, preferably improve (e.g., service admission management), congestion situations that would be revealed by the measurements carried out or the calculations resulting therefrom. Alternatively, the application module 165 is responsible for sending back to an orchestrator information relating to the measurements carried out or the calculations resulting therefrom.

[0065] [Fig.1C] schematically illustrates a complementary network probe arrangement.

[0066] In the diagram of [Fig. 1C], the network probe manager 160 comprises a control plane manager for each communication tunnel involving the router 110 with which the network probe in question is associated, i.e. for each local injector 150 and each local capture module 155.

[0067] Each control plane manager manages and configures the operations of an injector 150 and a capture module 155 associated with it. Said control plane manager implements the inter-probe communication protocol for the supervision of the communication tunnel for which said injector 150 and said module capture 155 operate. Said control plane manager performs, or coordinates, the traffic measurement operations via said communication tunnel, as well as any calculations which may result therefrom.

[0068] In [Fig. 1C], the network probe considered is associated with a router at the end of two communication tunnels. These communication tunnels may have the same termination point 120 in the router 110 in question, or two separate termination points 120. Two injectors INJ1 150a and INJ2 150b, and two respective capture modules CAP1 155a and CAP 2 155b, are thus represented in [Fig. 1C]. The network probe manager 160 then comprises two respective control plane managers CPM1 170a and CPM2 170b.

[0069] In the diagram of [Fig. 1C], the network probe manager 160 further comprises a memory 175, for example in the form of a database (DB). The memory in question may alternatively be external to the network probe manager 160, or even to the network probe itself, and the network probe manager 160 is connected to said memory and has read, write, and erase access to said memory. The memory 175 is notably used by the network probe manager 160 to store capture information carried out by each local capture module 155, measurements resulting therefrom, metrics linked to these measurements, and possibly results of calculations carried out on said metrics.

[0070] Other modular architectures than that presented above in relation to Figs. 1B and 1C can be designed without departing from the principles and behavior described here, in particular by distributing differently the functions performed by the modules set out above.

[0071] In a particular embodiment as illustrated in [Fig. 2], the network probes are in communication with an orchestrator 180, more particularly by means of their application modules 165. The measurements carried out by the network probes or calculations resulting therefrom can thus be shared with the orchestrator 180, in particular in order to detect and evaluate congestion situations on the communication network(s) 100a and thus adapt service admissions accordingly. Thus, the communication system is particularly suitable for SD-WAN (“Software-Defined Wide Area Network”) type infrastructures.In a particular embodiment, the orchestrator 180 defines and enforces a service admission policy in the communication network(s) 100a which takes into account the effective communication capacities in said communication network(s) 100a and which therefore takes into account the congestion situations revealed by the network probes.

[0072] Alternatively, the measurements carried out by the network probes or the calculation results resulting therefrom are shared with the orchestrator 180, in order to allow the orchestrator 180, or any other centralized device or computer system, to establish a predictive model of congestion of the communication network(s) 100a.

[0073] [Fig. 3] schematically illustrates an example of network probe hardware architecture, and in particular allowing the modular architecture of Figs. 1B and 1C to be implemented.

[0074] The network probe then comprises, connected by a communication bus 310: a processor or CPU (for “Central Processing Unit” in English) 301, or a cluster of such processors, such as for example GPUs (“Graphics Processing Units” in English); a RAM (for “Random Access Memory” in English) 302; a ROM (for “Read Only Memory” in English) 303, or a rewritable memory of the EEPROM type (“Electrically Erasable Programmable ROM” in English), for example of the Flash type; a data storage device, such as a hard disk HDD (for “Hard Disk Drive” in English) 304, or a storage media reader, such as an SD (for “Secure Digital” in English) card reader;a set of input and / or output interfaces, such as communication interfaces 305, allowing in particular the network probe to capture packets destined for the router with which the network probe is associated, or in transit via the router with which the network probe is associated, to inject and capture flag packets as described in more detail below, as well as to communicate with other network probes of the communication system or with the orchestrator 180.;

[0075] The processor 301 is capable of executing instructions loaded into the RAM 302 from the ROM 303, from an external memory (not shown), from a storage medium, such as an SD card or the HDD hard disk, or from a communication network. When the network probe is powered on, the processor 301 is capable of reading instructions from the RAM 302 and executing them. These instructions form a computer program causing the processor 301 to implement the steps, behaviors and algorithms described herein.

[0076] All or part of the steps, behaviors and algorithms described here can thus be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP (Digital Signal Processor) or a processor, or be implemented in hardware form by a machine or a dedicated component (chip) or a dedicated set of components (chipset), such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit).

[0077] It follows that the modular architecture of Figs. 1B and 1C can be implemented in software form by executing a set of instructions by a programmable machine, or be implemented in hardware form by a machine or a dedicated component or a set of dedicated components.

[0078] Generally, each network probe comprises electronic circuitry arranged and configured to implement the steps, behaviors and algorithms described herein, and in particular the modular architecture of Figs. 1B and 1C.

[0079] Note that the orchestrator 180 may also analogously comprise electronic circuitry arranged and configured to implement the steps and behaviors described here in relation to said orchestrator 180.

[0080] [Fig.4] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel upstream of said communication tunnel.

[0081] In a step 401, the network probe in question detects a new communication tunnel, one endpoint of which is the endpoint 120 with which said network probe is associated. The detection of a new communication tunnel is preferably carried out by detecting the transmission of a tunnel encapsulation packet, for example of the GRE, mGRE or IPSec type, corresponding to a communication tunnel which had not previously been detected. A new communication tunnel is thus detected when the source address and the destination address form a pair of endpoints 120 still unknown to said network probe (knowing that said network probe is associated with the entry endpoint 120 in the communication tunnel, for the direction of communication considered).

[0082] In a step 402, in a particular embodiment, the network probe deduces the address of a remote network probe, with which said network probe must collaborate for monitoring the traffic of the communication tunnel in question. To do this, said network probe retrieves the address of the remote termination point, i.e. the one on the other side of the communication tunnel that was newly detected in step 401. The source address corresponds to the termination point 120 with which said network probe is associated, so the address of the remote termination point is the destination address. Note that no deep packet inspection (DPI) is required. Said network probe then deduces the address of the remote network probe, with which said network probe must collaborate to monitor the communication tunnel in question, by applying the bijective translation function, as already explained above.This address deduction allows inter-probe communications and configuration of the local injector 150 to be established.

[0083] Thus, the network probe can perform an automatic instantiation of inter-probe communications between said network probe, which therefore supervises a first termination point 120 of the communication tunnel in question, and the remote network probe, which supervises the second termination point 120 of this communication tunnel. The automatic instantiation of inter-probe communications is achievable thanks to the predefinition of the addresses of the network probes relative to the addresses of their termination points. respective termination points. Preferably, each network probe opens a network socket with the address of the termination point 120 associated with it, to which the bijective translation function is applied, and with a dedicated UDP port. This allows each network probe to receive UDP messages that are addressed, by any other network probe in the communication system, to this address and this dedicated UDP port.

[0084] As already mentioned, other addressing plan sharing approaches can be implemented.

[0085] Thus, when a communication tunnel is set up between two termination points 120, each of the network probes monitoring one of the ends of said communication tunnel detects the transit of a packet of said communication tunnel.

[0086] In a step 403, the network probe instantiates a timing packet injector in the communication tunnel, i.e., a flag packet injector. By applying the same algorithm, the remote network probe also instantiates a timing packet injector in the communication tunnel, which makes it possible to create a reference clock in both directions of communication between the network probes via the communication tunnel.

[0087] In a step 404, the network probe performs data flow captures and measurements for the communication tunnel in question. The data flow measurements are performed by counting the volume of data transmitted between successive flag packets, detected in the outgoing traffic of the communication tunnel. The data flow measurements can be performed by type of service in the communication tunnel, for example by relying on type of service information (e.g. DSCP field) included in the encapsulation packets of the communication tunnel.

[0088] In a step 405, the network probe monitors the data traffic in the communication tunnel in question, based on the measurements made in step 404. The principle of monitoring the communication tunnel consists of comparing the measurements of the data rate entering the communication tunnel (at one termination point) and those of the data rate leaving the communication tunnel (at the other termination point). Information representative of the rate measurements made by a network probe is transmitted to the other network probe on the other side of the communication tunnel (potentially in both directions), and a difference between these rates beyond a predetermined margin highlights congestion. The flag packets serve as a clock reference to determine timing variations between the entry and exit of the communication tunnel, as schematically illustrated in [Fig.6].

[0089] A loop is then made between steps 405 and 404, so as to monitor the traffic in the communication tunnel in question, by time cycles defined by the frequency of transmission of the flag packets.

[0090] [Fig.5] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel downstream of a communication tunnel.

[0091] In a step 501, the network probe in question detects a new communication tunnel, one endpoint of which is the endpoint 120 with which said network probe is associated. The detection of a new communication tunnel is preferably carried out by detecting the reception of a tunnel encapsulation packet, for example of the GRE, mGRE or IPSec type, corresponding to a communication tunnel which had not previously been detected. A new communication tunnel is thus detected when the source address and the destination address form a pair of endpoints 120 still unknown to said network probe (knowing that said network probe is associated with the exit endpoint 120 of the communication tunnel, for the direction of communication considered).

[0092] In a step 502, in a particular embodiment, the network probe deduces the address of a remote network probe, with which said network probe must collaborate for monitoring the traffic of the communication tunnel in question. To do this, said network probe retrieves the address of the remote termination point, i.e. the one on the other side of the communication tunnel that was newly detected in step 501. The destination address corresponds to the termination point 120 with which said network probe is associated, so the address of the remote termination point is the source address. Note that no deep packet inspection is required. Said network probe then deduces the address of the remote network probe, with which said network probe must collaborate to monitor the communication tunnel in question, by applying the bijective translation function, as already explained above.Step 502 is the equivalent of step 402, on the other side of the communication tunnel, in order to allow inter-probe communications to be established.

[0093] As already mentioned, other addressing plan sharing approaches can be implemented.

[0094] In a step 503, the network probe performs data flow captures and measurements for the communication tunnel in question. The data flow measurements are performed by counting the volume of data received between successive flag packets, detected in the outgoing traffic of the communication tunnel. The data flow measurements can be performed by type of service in the communication tunnel, for example by relying on type of service information (e.g. DSCP field) included in the encapsulation packets of the communication tunnel.

[0095] In a step 504, the network probe monitors the data traffic in the communication tunnel in question, based on the measurements made in step 503. As already indicated, the flag packets serve as a clock reference to determine timing variations between the entry and exit of the communication tunnel, as schematically illustrated in [Fig.6].

[0096] A loop is then performed between steps 504 and 503, so as to monitor the traffic in the communication tunnel in question, by time cycles defined by the flag packets.

[0097] [Fig.6] schematically illustrates a variation in data flow timing in a communication tunnel T.

[0098] At the input of the communication tunnel, the data is transmitted (for example for a given type of service) according to a DR-tx rate. The injector 150 of the network probe at the input of the communication tunnel transmits, at a constant period, flag packets 1 to 7 in the data flow entering the communication tunnel. The flag packets 1 to 7 are therefore transmitted by the termination point 120 at the input of the communication tunnel at respective times t1 to t7 separated by a configured fixed period Ts. The period Ts can be defined as a function of a bandwidth and an expected (eg, theoretical) latency in the communication network 100a via which the communication tunnel T is established.

[0099] At the output of the communication tunnel, the data is received (for example for a given type of service) according to a DR-rx rate which typically differs from the DR-tx rate at the input of the communication tunnel T. The flag packets 1 and 3 to 7 are therefore received by the termination point 120 at the output of the communication tunnel at respective times t' 1 and t'3 to t'7 which are not separated by the fixed period Ts, and in [Fig. 6], packet 2 has been lost en route. The data flow has therefore undergone a variation in timing in the supervised communication tunnel T.

[0100] Thanks to the timestamp information contained in the flag packets, the network probe at the output of the communication tunnel is able to determine the timing at the input of the communication tunnel. By determining a timestamp of the flag packets received at the output of the communication tunnel (recovery of information representative of the instant of reception), the network probe at the output of the communication tunnel is able to determine the timing at the output of the communication tunnel. By comparing the timing at the input of the communication tunnel and the timing at the output of the communication tunnel, the variation in timing in the supervised communication tunnel T can be determined. The same reasoning can be applied at the input of the communication tunnel, as soon as the network probe upstream of the communication tunnel has recovered a timestamped history of measurements carried out by the remote network probe upon receipt of the flag packets.

[0101] [Fig.7] schematically illustrates a flowchart for creating and updating one or more measurement tables storing information representative of the variation in data flow timing as schematically illustrated in [Fig.6]. The flowchart of [Fig.7] is implemented by each network probe, and more particularly by each control plane manager (eg, CPM1 170a) in the modular architecture schematically illustrated in [Fig.1C].

[0102] In a step 701, the network probe obtains a data packet from the communication tunnel, resulting from the filtering carried out by the capture module 165 on all the data packets transiting (transmission / reception) via the termination point 120 with which said network probe is associated.

[0103] In a step 702, the network probe determines whether the data packet concerns the endpoint 120 with which said network probe is associated. If this is not the case, the algorithm is terminated in a step 708; otherwise, a step 703 is performed. In the case of an upstream network probe role with respect to the communication tunnel, the source address points to the endpoint 120 with which said network probe is associated. In the case of a downstream network probe role with respect to the communication tunnel, the destination address points to the endpoint 120 with which said network probe is associated.

[0104] In step 703, the network probe determines whether the filtered data packet comes from a communication tunnel already known to said network probe. Preferably, the measurements being carried out by type of service, the network probe further determines in which case whether the type of service is already known for the communication tunnel. The communication tunnel is already known if the source address and the destination address of the filtered packet form a pair of termination points 120 identified in the memory of the network probe. If the above conditions are verified, a step 705 is carried out; otherwise, a step 704 is carried out.

[0105] In step 704, the network probe creates a measurement table for the newly detected communication tunnel and / or a table for the newly detected service type. The network probe initializes each measurement table thus created.

[0106] For example, each measurement table is adapted to include 256 samples. When the measurement table in question becomes full, the network probe overwrites the oldest sample when said network probe must store a new sample in said measurement table.

[0107] In other words, the network probe instantiates in memory (in a database, for example) a descriptor, for the newly detected communication tunnel and / or the newly detected type of service, making it possible to subsequently store captures and metrics relating to data traffic measurements of said communication tunnel.

[0108] Then, step 705 is performed.

[0109] In step 705, the network probe determines whether the filtered data packet is a flag packet. If so, step 706 is performed; otherwise, step 707 is performed.

[0110] In step 706, the network probe creates a new entry in the measurement table that corresponds to the communication tunnel, and possibly to the type of service to which the flag packet corresponds. Each table entry corresponds to a sample.

[0111] In a particular embodiment, when the network probe has a role of upstream probe (i.e., network probe upstream of the communication tunnel in question for the direction of communication considered), each table entry includes:

[0112] - a timestamp information field as contained in the flag packet which caused the entry to be created in the measurement table;

[0113] - a sequence number field as contained in the flag packet that has caused the entry to be created in the measurement table;

[0114] - a data counting field passing through the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0115] And when the network probe has a downstream probe role (i.e., network probe downstream of the communication tunnel in question for the direction of communication considered), each table entry includes:

[0116] - a timestamp information field as contained in the flag packet which caused the entry to be created in the measurement table;

[0117] - a timestamp information field marking the instant at which the flag packet, which caused the entry to be created in the metrics table, was received (capture timestamp);

[0118] - a sequence number field as contained in the flag packet that has caused the entry to be created in the measurement table;

[0119] - a data counting field passing through the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0120] In another particular embodiment, the table entries have the same format regardless of the role, upstream or downstream, of the probe in question, namely:

[0121] - a timestamp information field as contained in the flag packet which caused the entry to be created in the measurement table;

[0122] - a timestamp information field marking the time at which the flag packet, which caused the entry in the measurement table to be created, was captured (whether upstream or downstream of the communication tunnel, depending on the direction of communication to which the table of measurements in question applies);

[0123] - a sequence number field as contained in the flag packet that has caused the entry to be created in the measurement table;

[0124] - a data counting field passing through the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0125] An example of a measurement table structure, for a considered communication tunnel and preferably a type of service (eg, DSCP) considered in said communication tunnel, is schematically illustrated in [Fig.8].

[0126] The example in [Fig.8] applies both upstream and downstream of the communication tunnel. The measurement table structure illustrated in [Fig.8] has six columns, referenced from 801 to 806.

[0127] For each sample, column 801 contains a sample Idx index value in the measurement table. Here, the Idx index values ​​are presented in column 801 in ascending order, from 0 to 255. The Idx index values ​​are representative of the order in which the flag packets processed in said measurement table were captured (in a rotating manner, i.e., when the entry with Idx index value equal to 255 is filled, the next entry to be manipulated is the one with Idx index value equal to 0).

[0128] For each sample, column 802 contains a sequence number Seq as contained in the flag packet which caused the creation, in the measurement table, of the entry corresponding to the index value Idx in question.

[0129] For each sample, column 803 contains FTS timestamp information as contained in the flag packet which caused the creation, in the measurement table, of the entry corresponding to the index value Idx in question.

[0130] For each sample, column 804 contains a CTS timestamp information marking the instant at which the flag packet, which caused the creation of the entry in the measurement table, of the entry corresponding to the index value Idx in question was captured.

[0131] For each sample, column 805 contains QoP information on the quantity of packets transiting in the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable). The QoP information indicates the quantity of packets captured between the flag packet, which caused the creation in the measurement table, of the entry corresponding to the index value Idx in question and the next flag which caused the creation in the measurement table, of the entry corresponding to the following index value Idx, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0132] For each sample, column 806 contains QoB information on the quantity of bytes transiting in the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable). The QoB information indicates the quantity of bytes captured between the flag packet, which caused the creation in the measurement table, of the entry corresponding to the index value Idx in question and the next flag which caused the creation in the measurement table, of the entry corresponding to the following index value Idx, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0133] In [Fig.8], a sample is stored on each row of the measurement table.

[0134] A line 811 stores a sample, with the index value Idx equal to 0, of which:

[0135] - the sequence number Seq is equal to 38;

[0136] - the timestamp information contained in the flag packet corresponding to a value X0 which is equal to X, where X is a reference time;

[0137] - the capture timestamp information of the corresponding flag packet has a value X'0 which is equal to X0+L0, where L0 is a capture latency duration relative to the time X0 when the flag packet in question was sent.

[0138] A line 812 stores a sample, with the index value Idx equal to 1, of which:

[0139] - the sequence number Seq is equal to 39;

[0140] - the timestamp information contained in the flag packet corresponding to a value XI which is equal to X+TS, where TS is a fixed predefined value of flag packet timing period;

[0141] - the capture timestamp information of the corresponding flag packet has a value X' 1 which is equal to Xl+Ll, where L1 is a capture latency duration relative to the instant XI when the flag packet in question was sent.

[0142] A line 814 stores a sample, at the index value Idx equal to 255, of which:

[0143] - the sequence number Seq is equal to 293;

[0144] - the timestamp information contained in the flag packet corresponding to a value X255 which is equal to X+255*TS;

[0145] - the capture timestamp information of the corresponding flag packet has a value X'255 which is equal to X255+L255, where L255 is a capture latency time relative to the X255 time the flag packet in question was sent.

[0146] During the counting operations, columns 805 and 806 are updated to indicate respectively the quantities of packets captured and the quantities of bytes captured between successively captured flag packets. Thus, after filling: line 811 contains in column 805 a QoPO packet count measurement, and in column 806 a QoBO byte count measurement; line 812 contains in column 805 a QoPl packet count measurement, and in column 806 a QoBl byte count measurement; and row 814 contains in column 805 a QoP255 packet count measurement, and in column 806 a QoB255 byte count measurement.

[0147] The example measurement table of [Fig.8] contains other lines 813 containing other samples, between line 812 and line 814, which are not further detailed in this example.

[0148] Note that, since flag packets may be lost, it is possible that two successive samples in the measurement table have sequence numbers that do not follow each other. This situation occurs more particularly downstream of the communication tunnel, when congestion on the path taken by the communication tunnel has caused packet losses.

[0149] Returning to [Fig.7], step 708 is performed, where the algorithm is terminated.

[0150] In step 707, the network probe performs a count of the packets transiting in the communication tunnel, for the considered communication direction. The received filtered packet is taken into account in the current sample in the corresponding table. For example, a number of packets received following the flag packet that resulted in the creation of the corresponding entry in the table is incremented by one. In addition, a quantity of data received following the flag packet that resulted in the creation of the corresponding entry in the table is incremented by the size of the filtered packet. It should be noted that by proceeding in this way, the flag packets are not taken into account in the count. It is also possible to take the flag packets into account in the count; in this case, step 706 is followed by step 707 and not by step 708.

[0151] The same counting mechanism is thus preferentially applied upstream and downstream of the communication tunnel considered.

[0152] Then, step 708 is performed, where the algorithm is terminated.

[0153] By doing this, a history of the samplings carried out by the network probe is stored in memory.

[0154] The sampling histories on either side of the communication tunnel make it possible to detect and evaluate congestion situations, whether in terms of latency, jitter or packet loss during transit in the communication tunnel. The inter-probe protocol allows the network probes supervising the same communication tunnel, or the orchestrator 180, to collect these sampling histories, or information derived therefrom by calculations, on either side of the communication tunnel, in order to evaluate possible congestion situations.

[0155] In a particular embodiment, one of the network probes (typically the network probe upstream of the communication tunnel, in a considered communication direction) asks the other network probe on the other side of the communication tunnel to transmit to it in response sampling history data or information derived therefrom by calculations. A MeasReq request is transmitted for this purpose within the framework of the inter-probe protocol. Preferably, the request includes a field indicating an interval of sequence numbers of flag packets for which the history, or said information derived therefrom by calculations, must be provided in response. Preferably, the MeasReq request itself includes a sequence number of its own, which is included in a MeasResp response providing the requested sampling history, in order to facilitate the request-response association.

[0156] When a network probe receives a MeasReq request from its peer on the other side of the tunnel, said network probe determines which sampling history interval is concerned by the request. The network probe then retrieves the requested sampling history in memory. If, due to packet losses (e.g., loss of the flag 2 packet in [Fig. 6]), the sampling history available in memory of said probe does not correspond to the requested sampling history, then the network probe retrieves the sampling history closest to the requested sampling history in memory and transmits it, or information derived from it by calculation, in the MeasResp response. The MeasResp response includes information indicating which sampling history interval is actually returned, or respectively which sampling history interval was actually used to derive the returned information.

[0157] For example, based on [Fig.6], a MeasReq request requests the sampling history for the flag packet sequence number range 2 through 6. Since flag packet 2 was lost en route, the MeasResp response includes the sampling history for the flag packet sequence number range 1 through 6. Alternatively, the MeasResp response includes the sampling history for the flag packet sequence number range 3 through 6.

[0158] [Fig.9] schematically illustrates a flowchart of collaboration of network probes PI 901 and P2 902 for evaluating a congestion situation in a communication tunnel, in a first embodiment.

[0159] In a step 910, the PI network probe 901, upstream of the communication tunnel, sends a MeasReq request to the P2 probe 902, downstream of the communication tunnel. The MeasReq request is of type MeasReq 1, and preferably includes an indication of at least one type of service (e.g., DSCP), as well as a field indicating an interval of sequence numbers of flag packets, for which results of latency, jitter and volume calculations must be provided in response. The calculations are carried out by the P2 902 probe in view of the sampling history stored by the P2 902 probe with respect to said type(s) of service specified in the MeasReq request in the communication tunnel in question. If not implicit in the inter-probe protocol, the MeasReq request indicates which communication tunnel is concerned, and which direction of communication is also concerned (for example, by indicating a source 120 endpoint address and a destination 120 endpoint address).

[0160] In a particular embodiment, the sequence number interval is notified in the MeasReq request only by a lower bound sequence number of the interval in question, it being implicitly understood that the upper bound of the interval in question ends at the last flag packet received by the P2 probe 902.

[0161] Preferably, the PI network probe 901 stores the sequence number Seq of the last flag packet locally captured and the current volume as seen by the PI network probe 901 at the time of sending the MeasReq request. This subsequently allows the PI network probe 901 to estimate the loss of data volume in the case where all the flag packets are lost over the interval of flag packet sequence numbers to which the MeasReq request applies.

[0162] In a step 911, the network probe P2 902 receives the MeasReq request sent by the probe PI 901.

[0163] In a step 912, the P2 network probe 902 searches for the sequence number interval to which the MeasReq request relates, based on the indications contained in said MeasReq request. If, due to packet losses, the sampling history available in the memory of the P2 network probe 902 does not correspond to the sampling history requested by the PI network probe 901, then the P2 network probe 902 finds in memory the sampling history closest to the sampling history requested by the PI network probe 901.

[0164] In a step 913, the network probe P2 902 selects the appropriate measurement table(s) based on the type(s) of service (e.g., DSCP) concerned, and retrieves the samples (measurements) which correspond to the sequence number interval sought and which are contained in this or these measurement tables. This retrieval of samples delimits a calculation zone among the sampling history stored by the network probe P2 902.

[0165] In a step 914, the network probe P2 902 performs latency, jitter and volume calculations, for each type of service required. Referring to [Fig.8], the network probe P2 902 uses the difference between column 804 and column 803. Preferably, the network probe P2 902 calculates:

[0166] - the minimum transit latency of the flag packets of the number interval of sequence considered;

[0167] - the maximum transit latency of the flag packets of the number interval of sequence considered;

[0168] - the average transit latency of the flag packets of the number interval of sequence considered;

[0169] - the minimum jitter experienced by the flag packets of the number interval of sequence considered;

[0170] - the maximum jitter experienced by the flag packets of the number interval of sequence considered;

[0171] - the average jitter experienced by the flag packets of the number interval of sequence considered;

[0172] - the volume of data transit (quantity of packets, bytes, etc.) in the tunnel communication on the sequence number interval considered.

[0173] The network probe P2 902 then prepares a MeasResp response. The MeasResp response is of type MeasResp 1, suitable for providing the information requested by the MeasReq request of type MeasReql.

[0174] The P2 902 network probe adds the following retrieved information to the MeasResp response, for each type of service required:

[0175] - the sequence number interval actually considered;

[0176] - the current volume (i.e., at the time the MeasReq request is received) of the last flag packet received and the sequence number Seq of said last flag packet received.

[0177] Then, in a step 915, the network probe P2 902 sends the response MeasResp, of type MeasResp 1, thus prepared. The response MeasResp is sent to the network probe PI 901 in response to the request MeasReq received in step 911.

[0178] In a step 916, the PI network probe 901 receives the MeasResp response sent by the P2 probe 902.

[0179] In a step 917, the PI network probe 901 calculates a possible loss of data volume (packets, bytes, etc.) over the sequence number interval actually considered by the P2 network probe 902 to perform its calculations and construct the MeasResp response. The loss of data volume corresponds to the difference between the volume calculated by the PI network probe 901 with respect to its own sampling history, over the sequence number interval actually considered by the P2 network probe 902, and the volume transmitted by the P2 network probe 902 in the MeasResp response.

[0180] When the sequence numbers constituting the bounds of the sequence number interval of the history returned in the MeasResp response are the same, a total loss of the flag packets between two successive measurements has occurred. In this case, the latency and jitter values ​​transmitted by the P2 network probe 902 are not taken into account by the PI network probe 901. The PI network probe 901 then calculates an approximate value of the loss of data volume. Indeed, when a flag packet has been lost, the volume is accumulated in reception on the sample of the last flag packet received (that is to say, considering that the flag packet with sequence number S2 has been lost, the volume in reception associated with the sequence number SI = S2-1 accumulates the volume of packets not lost on the way which were transmitted between the flag packet with sequence number SI and the flag packet with sequence number S3=S2+1 instead of simply the volume of packets not lost on the way which were transmitted between the flag packet with sequence number SI and the flag packet with sequence number S2).Thus, by considering two successive MeasResp responses, the PI network probe 901 can estimate the loss of data volume by determining the difference in "current volume" information as indicated in said two successive MeasResp responses, and by comparing it with the difference in "current volume" information as stored when sending the corresponding MeasReq requests.

[0181] In a step 918, the PI network probe 901 stores information making it possible to know where the monitoring of the communication tunnel is with respect to the sampling histories, for the type(s) of service (eg, DSCP) considered. Typically, the PI network probe 901 stores the sequence number Seq of the last flag packet received and the current volume, as indicated by the P2 network probe 902 in the MeasResp response.

[0182] In a step 919, using the latency and jitter information transmitted by the P2 network probe 902 and the calculation of possible loss of data volume in step 917, the PI network probe 901 evaluates whether a possible congestion situation is encountered by the communication tunnel, whether in terms of latency, jitter, or packet losses during transit in the communication tunnel. Thanks to this congestion situation evaluation, the PI network probe 901 can instruct the local router to modify data transmission profiles in the communication network(s) 100a so as to take into account, preferably improve (e.g., service admission management), the congestion situations that would be revealed. Alternatively, the PI network probe 901 sends back to the orchestrator 180 information relating to the calculations, so as to allow the orchestrator 180 to adjust the service admission management.

[0183] Performing the latency, jitter and volume calculations on reception allows the MeasResp message to be small compared to sending the raw measurements. Thus, the inter-probe protocol has a reduced cost on bandwidth consumption.

[0184] However, rather than the calculations of latency, jitter and volume in reception being carried out by the downstream network probe, these calculations can be carried out by the upstream probe. The upstream probe must then recover all or part of the sampling history of the downstream probe. This approach is particularly advantageous when the injector 150 is placed upstream of the local termination point 120 and the local router itself involves a transit latency that is not negligible compared to the transit latency of the supervised communication tunnel. This situation is presented below in relation to [Fig. 10].

[0185] [Fig. 10] schematically illustrates a flowchart of collaboration of network probes P3 1001 and P4 1002 to evaluate a congestion situation in a communication tunnel, in a second embodiment. In this second embodiment, all of the calculations are carried out by the upstream probe, the downstream probe simply transmitting all or part of the content of its measurement table(s).

[0186] In a step 1010, the network probe P3 1001, upstream of the communication tunnel, sends a MeasReq request to the probe P4 1002, downstream of the communication tunnel. The MeasReq request is of type MeasReq2, and preferably includes an indication of at least one type of service (e.g., DSCP) for which the sampling history must be provided in response. If this is not implicit in the inter-probe protocol (for example, the entire measurement table(s) concerned), the MeasReq request contains a field indicating an interval of sequence numbers of flag packets, for which the sampling history must be provided in response. If this is not implicit in the inter-probe protocol, the MeasReq request indicates which communication tunnel is concerned, and which direction of communication is also concerned (for example, by indicating an address of source endpoint 120 and destination endpoint 120).

[0187] Preferably, the network probe P3 1001 stores the sequence number Seq of the last flag packet locally captured and the current volume as seen by the network probe P3 1001 at the time of sending the MeasReq request. This subsequently allows the network probe P3 1001 to estimate the loss of data volume in the case where all the flag packets are lost over the interval of flag packet sequence numbers to which the MeasReq request applies.

[0188] In a step 1011, the network probe P4 1002 receives the MeasReq request sent by the probe P3 1001.

[0189] In an optional step 1012, the P4 network probe 1002 searches for the sequence number range to which the MeasReq request relates. Step 1012 is optional in that the inter-probe protocol may imply that the MeasReq request relates to the entire sampling history available from the P4 network probe 1002. Otherwise, the P4 network probe 1002 searches for the sequence number range sequence according to the indications contained in said MeasReq request. If due to packet losses, the sampling history available in memory of the P4 network probe 1002 does not correspond to the sampling history requested by the P3 network probe 1001, then the P4 network probe 1002 finds in memory the sampling history closest to the sampling history requested by the P3 network probe 1001.

[0190] In a step 1013, the network probe P4 1002 selects the appropriate measurement table(s) based on the type(s) of service (e.g., DSCP) concerned, and retrieves the samples (measurements) which correspond to the desired sequence number interval and which are contained in this or these measurement table(s).

[0191] The network probe P4 1002 then prepares a MeasResp response. The MeasResp response is of type MeasResp2, adapted to provide the information requested by the MeasReq request of type MeasReq2. The MeasResp response includes the samples (measurements) retrieved in step 1013.

[0192] The P4 1002 network probe preferentially includes in the MeasResp response the following retrieved information, for each type of service required:

[0193] - the sequence number interval actually considered;

[0194] - the current volume (i.e., at the time the MeasReq request is received) of the last flag packet received and the sequence number Seq of said last flag packet received.

[0195] In a step 1014, the network probe P4 1002 sends the MeasResp response, of type MeasResp2, thus prepared. The MeasResp response is sent to the network probe P3 1001 in response to the MeasReq request received in step 1011.

[0196] In a step 1015, the network probe P3 1001 receives the MeasResp response sent by the probe P4 1002. The network probe P3 1001 thus knows the list of flag packets actually captured by the network probe P4 1002 (and therefore by deduction, those which were lost along the way).

[0197] In a step 1016, the network probe P3 1001 performs latency, jitter and volume calculations, for each type of service required, using the sampling history received in the MeasResp response. Based on the same data, the network probe P3 1001 can perform the same calculations as the network probe P2 902 in step 914. Thus, preferably, the network probe P3 1001 calculates:

[0198] - the minimum transit latency of the flag packets of the number interval of sequence considered;

[0199] - the maximum transit latency of the flag packets of the number interval of sequence considered;

[0200] - the average transit latency of the flag packets of the number interval of sequence considered;

[0201] - the minimum jitter experienced by the flag packets of the number interval of sequence considered;

[0202] - the maximum jitter experienced by the flag packets of the number interval of sequence considered;

[0203] - the average jitter experienced by the flag packets of the number interval of sequence considered;

[0204] - the volume of data transit (quantity of packets, bytes, etc.) in the tunnel communication on the sequence number interval considered.

[0205] The network probe P3 1001 further calculates a possible loss of data volume (packets, bytes, etc.) over the sequence number interval actually considered (due to possible losses of flag packets). The loss of data volume corresponds to the difference between the volume calculated by the network probe P3 1001 with respect to its own sampling history, over the sequence number interval actually considered, and the volume calculated by the network probe P3 1001 with respect to the sampling history received in the MeasResp response.

[0206] When the sequence numbers constituting the bounds of the sequence number interval of the history returned in the MeasResp response are the same, a total loss of the flag packets between two successive measurements has occurred. In this case, the latency and jitter values ​​are not calculated by the network probe P3 1001. The network probe P3 1001 then calculates an approximate value of the loss of data volume, as already explained above in relation to [Fig.9]. Thus, by considering two successive MeasResp responses, the network probe P3 1001 can estimate the loss of data volume by determining the difference in “current volume” information as indicated in said two successive MeasResp responses, and by comparing it with the difference in “current volume” information as stored when sending the corresponding MeasReq requests.

[0207] In a step 1017, the network probe P3 1001 stores information making it possible to know where the monitoring of the communication tunnel is with respect to the sampling histories, for the type(s) of service (eg, DSCP) considered. Typically, the network probe P3 1001 stores the sequence number Seq of the last flag packet received and the current volume, as provided by the network probe P4 1002 in the response MeasResp.

[0208] In a step 1018, thanks to the calculations of latency, jitter and possible loss of data volume in step 1016, the network probe P3 1001 evaluates whether a possible congestion situation is encountered by the communication tunnel, whether in terms of latency, jitter, or packet losses during transit in the communication tunnel. Thanks to this congestion situation evaluation, the network probe P3 1001 can instruct the local router to modify transmission profiles of data in the communication network(s) 100a so as to take into account, preferably improve (e.g., service admission management), the congestion situations which would be revealed. Alternatively, the network probe P3 1001 sends back to the orchestrator 180 information relating to the calculations, so as to allow the orchestrator 180 to adjust the service admission management.

[0209] It should be noted that the algorithm of [Fig. 10] can be reversed, i.e. the downstream probe obtains the sampling history of the upstream probe and performs all the calculations.

[0210] In a particular embodiment applicable to the algorithms of Figs. 9 and 10, the network probe P3 1001 calculates additional latency information and additional jitter information, which are linked to the quality of service QoS (Quality of Service) of the local router itself, by comparing the timestamp information contained in the flag packets sent and the capture timestamp information of the flag packets captured by said network probe P3 1001. The latency in the communication tunnel is then adjusted by subtracting the latency induced by the router from the latency calculation performed on the basis of the samples received from the network probe P4 1002. Similarly, the jitter in the communication tunnel is then adjusted by subtracting the jitter induced by the router from the jitter calculation performed on the basis of the samples received from the network probe P4 1002.According to a complementary embodiment, the network probe P3 1001 further estimates a possible loss of data volume linked to the local router itself. Given that the network probe P3 1001 does not know the volume of data actually coming from the communication network 100b upstream of the termination point 120 100b, the network probe P3 1001 makes an estimate of a possible loss of data volume coming from the communication network 100b based on the possible losses suffered by its own flag packets (i.e., those injected by the local injector 150 and which must normally be detected by the local capture point of the upstream network probe).

[0211] In a particular embodiment applicable to the algorithms of Figs. 9 and 10, when the communication tunnels are implemented using the GRE protocol or the mGRE protocol, the flag packets can be injected and captured by type of service (eg, DSCP) and furthermore by flow (eg, LAN IP flow). The flow information per flag packet is then taken into account by the network probes and the calculations of volume and possible loss of data volume are carried out by flow and by type of service, instead of being carried out by type of service only.

[0212] A particular hybrid embodiment compared to the algorithms of Figs. 9 and 10 can also be implemented. The volumetric calculation is then carried out by the downstream network probe, and the latency and jitter calculations are carried out by the upstream network probe. To do this, the MeasResp response is of type MeasResp3. The response MeasResp then includes the Seq sequence number and timestamp information, but not the data volume information. In relation to [Fig.8], the data contained in columns 805 and 806 are omitted. The MeasResp response also includes the volume calculation result performed by the downstream network probe. The MeasResp response can, however, also include the current volume (i.e., at the time the MeasReq request is received) of the last received flag packet and the Seq sequence number of said last received flag packet. This allows a compromise to be found in terms of bandwidth consumption by the inter-probe protocol, while maintaining the accuracy of the latency and jitter calculation results.

Claims

Claims

1. A method implemented in a communication system comprising a plurality of routers (110), a first network probe being associated with a first router (110) of said plurality of routers (110) and with a first termination point (120) of the first router (110), a second network probe being associated with a second router (110) of said plurality of routers (110) and with a second termination point (120) of the first router (110), each network probe being configured to perform data flow rate measurements entering a communication tunnel between the first termination point (120) and the second termination point (120) and leaving said communication tunnel, the method comprising the following steps in the context of monitoring traffic in the communication tunnel: - periodically injecting, by the first network probe, in parallel with the traffic of the communication tunnel,flag packets delimiting time periods over which the data flow measurements are carried out, each flag packet including time stamp information expressing a time reference for injection of said flag packet; - collecting information relating to a variation in the timing of data flow in the communication tunnel, the variation in the timing of data flow being measured using a difference between the time stamp information contained in the flag packets and time stamp information of the instant of capture of said flag packets by the second network probe; - evaluating possible congestion situations experienced by the communication tunnel based on said collected information.,

2. Method according to claim 1, comprising the following step: - calculating a possible loss of data volume in the communication tunnel, by comparison between a count of data volume at the output of the communication tunnel between successive flag packets, detected by the second network probe, and a count of data volume at the input of the communication tunnel between successive flag packets, detected by the first network probe.

3. Method according to claim 1 or 2, in which the flag packets are UDP type packets transmitted on a port dedicated to said flag packets.

4. A method according to any one of claims 1 to 3, wherein the flag packets are injected for each service type among a plurality of service types carried by the communication tunnel.

5. A method according to any one of claims 1 to 4, wherein the flag packets are injected into a user plane upstream of the first termination point relative to the communication tunnel.

6. Method according to any one of claims 1 to 5, in which, to collect the information relating to a variation in the timing of data flows in the communication tunnel, at least the second network probe comprises at least one measurement table for storing a sampling history of flag packets captured at the output of the communication tunnel, each entry of the measurement table corresponding to a sample comprising: - a timestamp information field as contained in the flag packet corresponding to the sample in question; - a timestamp information field marking the instant at which the flag packet corresponding to the sample in question was captured; - a sequence number field as contained in the flag packet corresponding to the sample in question;and - a data count field transiting in the communication tunnel between the flag packet corresponding to the sample in question and the flag packet corresponding to the next sample in the measurement table.;

7. The method of claim 6, wherein the first network probe transmits to the second network probe a request to transmit in response information derived by calculations of a sampling history of the flag packets received by the second network probe, the request involving an interval of sequence numbers to be considered, the calculations being intended to evaluate possible congestion situations and including: - a minimum transit latency of the flag packets of said interval of sequence numbers; - a maximum transit latency of the flag packets of said interval of sequence numbers; - an average transit latency of the flag packets of said interval of sequence numbers; - a minimum jitter experienced by the flag packets of said interval of sequence numbers; - a maximum jitter experienced by the flag packets of said sequence number interval; - an average jitter experienced by said sequence number interval; - a volume of data transit in the communication tunnel over said sequence number interval.

8. The method of claim 6, wherein the first network probe transmits to the second network probe a request requiring the transmission in response of all or part of the sampling history of the flag packets received by the second network probe, the first network probe then performing calculations intended to evaluate possible congestion situations and including: - a minimum transit latency of the flag packets of said sequence number interval; - a maximum transit latency of the flag packets of said sequence number interval; - an average transit latency of the flag packets of said sequence number interval; - a minimum jitter experienced by the flag packets of said sequence number interval; - a maximum jitter experienced by the flag packets of said sequence number interval; - an average jitter experienced by said sequence number interval; - a volume of data transit in the communication tunnel over said sequence number interval.

9. Method according to any one of claims 1 to 8, in which the first network probe comprises at least one other measurement table for storing a history of samplings of flag packets captured at the input of the communication tunnel, each entry of this other measurement table corresponding to a sample comprising: - a timestamp information field as contained in the flag packet corresponding to the sample in question; - a timestamp information field marking the time at which the flag packet corresponding to the sample in question was captured; - a sequence number field as contained in the flag packet corresponding to the sample in question; and - a data count field transiting in the communication tunnel between the flag packet corresponding to the sample in question and the flag packet corresponding to the next sample in the table of measures.

10. The method of claim 9, wherein the first network probe calculates additional latency information and additional jitter information, which are related to the quality of service of the first router, by comparing the timestamp information contained in the injected flag packets and the capture timestamp information of the flag packets captured by said first network probe.

11. The method of claim 10, wherein the first network probe further estimates a possible loss of data volume which is linked to the quality of service of the first router, from detection of losses of flag packets injected by the first network probe.

12. A communication system comprising network probes and a plurality of routers (110), a first network probe being associated with a first router (110) of said plurality of routers (110) and with a first termination point (120) of the first router (110), a second network probe being associated with a second router (110) of said plurality of routers (110) and with a second termination point (120) of the first router (110), each network probe being configured to perform data flow measurements entering a communication tunnel between the first termination point (120) and the second termination point (120) and leaving said communication tunnel, the communication system comprising electronic circuitry configured to perform the following steps in the context of monitoring traffic in the communication tunnel: - periodically injecting, by the first network probe,in parallel with the traffic of the communication tunnel, flag packets delimiting time periods over which the data flow measurements are carried out, each flag packet including time stamp information expressing a time reference for injection of said flag packet; - collecting information relating to a variation in the timing of data flow in the communication tunnel, the variation in the timing of data flow being measured using a difference between the time stamp information contained in the flag packets and time stamp information of the instant of capture of said flag packets by the second network probe; - evaluating possible congestion situations experienced by the communication tunnel based on said collected information.,

Images