COMMUNICATIONS TRAFFIC MONITORING PROTOCOL

Description

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 provide a wide variety of services, such as voice communication, typically VoIP (Voice over IP) services, audiovisual communication, multimedia program broadcasting, or data access, typically access to web services. These services have different transmission latency requirements in communication networks, and have different priorities.

[0003] The communication links on which communication networks are based are based on physical transmission technologies that can be very diverse. Each of these technologies leads to different properties of the transmission channel used in terms of capacity, 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 detailed assessment of the congestion states of these communication networks.

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

[0007] Note that document EP 2 296 318 A1 is known, disclosing a device used as a slave clock in the context of a PTP (Precision Time Protocol) type protocol, making it possible to determine a transit time precisely in relation to a master clock. STATEMENT OF THE INVENTION

[0008] For this purpose, the invention relates to a method implemented in a communication system comprising a plurality of routers according to claim 1 and a corresponding communication system according to claim 12. The dependent claims present particular embodiments of the invention. Furthermore, 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 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 a 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 time stamp information contained in the flag packets and time stamp 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 reception of the flag packets compared to their timing of transmission 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.,

[0009] 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.

[0010] 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.

[0011] 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.

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

[0013] In a particular embodiment, to collect information relating to a variation in data flow timing 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 counting field passing through 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.;

[0014] 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.;

[0015] 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.

[0016] In a particular embodiment, the first network probe comprises at least one other measurement table for storing a sampling history 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 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 counting 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.

[0017] In a particular embodiment, 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. Thus, the involvement of the router in question in congestion situations can be easily evaluated.

[0018] 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.

[0019] 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

[0020] The following description of at least one embodiment is set forth in connection with the accompanying drawings, among which: [ Fig. 1A ] schematically illustrates a communication system; [ Fig. 1B ] schematically illustrates a network probe arrangement; [ Fig. 1C ] schematically illustrates a complementary network probe arrangement; [ Fig. 2 ] schematically illustrates a connection of network probes with an orchestrator; [ Fig. 3 ] schematically illustrates an example of hardware architecture allowing the implementation of network probes of the communication system; [ Fig. 4 ] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel upstream of said communication tunnel; [ Fig. 5 ] schematically illustrates a flowchart for setting up a network probe for monitoring a communication tunnel downstream of said communication tunnel; [ Fig. 6 ] schematically illustrates a variation in data flow timing in a communication tunnel; [ 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 of the Fig. 6 ; [ Fig. 8 ] schematically illustrates an example of a measurement table structure; [ Fig. 9 ] schematically illustrates a network probe collaboration flowchart for assessing a congestion situation in a communication tunnel, in a first embodiment; and [ Fig. 10 ] schematically illustrates a network probe collaboration flowchart for assessing a congestion situation in a communication tunnel, in a second embodiment. DETAILED PRESENTATION OF IMPLEMENTATION METHODS

[0021] There Fig. 1A schematically illustrates a communication system.

[0022] The communication system comprises a plurality of routers 110. Three routers R1 to R3 are shown, for illustration purposes, in the Fig. 1A 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.

[0023] 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 the Fig. 1A .

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

[0025] 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 located between the two termination points 120 of the communications tunnel.

[0026] For example, communication tunnels are used to connect other communication networks 100b through said routers 110. As illustrated in the 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 from 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) through the wide area network (WAN1) 100a (called black network). Thus, as an illustration on the Fig. 1A , a first communication tunnel is established on the WAN1 network between an endpoint E1 of the router R1 and an endpoint E3 of the router R2, and a second communication tunnel is established on the WAN1 network between the endpoint E1 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 R1 and an endpoint 120 of another router not shown.

[0027] 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.

[0028] 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 clock 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.

[0029] 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.

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

[0031] A said network probe is thus associated with each endpoint 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 endpoints 120.

[0032] In a particular embodiment, the network probes are arranged as schematically illustrated in the Fig. 1B .

[0033] There 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.

[0034] 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 endpoint 120.

[0035] 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 endpoint 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 endpoint 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 considered.

[0036] It should be noted that some of the content of flag packets, not required 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 to which the flag packets in question are associated.

[0037] 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.

[0038] 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, flag packets are injected by the injector 150 for each DSCP (Differentiated Services Code Point) field value of the packets in the communication tunnel.

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

[0040] 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 type of service field (e.g., DSCP type) indicating the type of service in which the flag packet in question is registered. The routing header has a size of 20 to 40 bytes, for example. 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 network probes in the communication system). The transport header has a size of 8 bytes, for example. 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.

[0041] The network probe manager 160 is configured and arranged to store metrics related to measurements made 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.

[0042] 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.

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

[0044] More specifically, the address of the network probe is determined by applying a one-to-one translation function with respect to the address of the endpoint 120 with which said network probe is associated.

[0045] 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.

[0046] 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.

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

[0048] The same mechanism applies for defining the addresses of other network probes in 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 endpoint 120 with which said remote network probe is associated.

[0049] In an alternative embodiment, the network probes have addresses independent of the addresses of the communication tunnel endpoints 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 endpoints 120 are concerned by the discovered communication tunnel. The remote probe being configured to receive (listen) the messages received on this dedicated port, this remote probe can recognize the communication tunnel (the endpoint 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 addressing plan mentioned above.

[0050] 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 that 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 that 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.

[0051] 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.

[0052] 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), the congestion situations which would be revealed by the measurements carried out or the calculations which result therefrom. Alternatively, the application module 165 is responsible for sending back to an orchestrator information relating to the measurements carried out or the calculations which result therefrom.

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

[0054] In the diagram of the 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.

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

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

[0057] In the diagram of the 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.

[0058] Other modular architectures than the one presented above in relation to the Figs. 1B And 1Cmay 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.

[0059] In a particular embodiment as illustrated in the 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 the 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 suited to SD-WAN (“Software-Defined Wide Area Network” in English) type infrastructures. In a particular embodiment, the orchestrator 180 defines and imposes (“enforces” in English) 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.

[0060] Alternatively, the measurements made 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.

[0061] There Fig. 3 schematically illustrates an example of network probe hardware architecture, and in particular allowing the implementation of the modular architecture of Figs. 1B And 1C .

[0062] 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.;

[0063] 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.

[0064] 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).

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

[0066] 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 the Figs. 1B And 1C .

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

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

[0069] 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).

[0070] 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 endpoint, 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 endpoint 120 with which said network probe is associated, so the address of the remote endpoint 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.

[0071] Thus, the network probe can perform an automatic instantiation of inter-probe communications between said network probe, which therefore supervises a first endpoint 120 of the communication tunnel in question, and the remote network probe, which supervises the second endpoint 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 respective endpoints. Preferably, each network probe opens a network connector (“socket” in English) with the address of the endpoint 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 which are addressed, by any other network probe of the communication system, to this address and this dedicated UDP port.

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

[0073] Thus, when a communication tunnel is set up between two endpoints 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.

[0074] 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, thereby creating a reference clock in both directions of communication between the network probes via the communication tunnel.

[0075] 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.

[0076] 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 endpoint) and those of the data rate leaving the communication tunnel (at the other endpoint). 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 the exit of the communication tunnel, as schematically illustrated in the Fig. 6 .

[0077] A loop is then performed 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.

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

[0079] 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).

[0080] 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 endpoint, 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 endpoint 120 with which said network probe is associated, so the address of the remote endpoint 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.

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

[0082] 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.

[0083] In a step 504, the network probe performs a monitoring of 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 the exit of the communication tunnel, as schematically illustrated in the Fig. 6 .

[0084] 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.

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

[0086] 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 an expected (eg, theoretical) bandwidth and latency in the communication network 100a via which the communication tunnel T is established.

[0087] 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 on the Fig. 6 , packet 2 was lost en route. The data stream therefore experienced a timing variation in the supervised T communication tunnel.

[0088] Using 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 timing variation 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 made by the remote network probe upon receipt of the flag packets.

[0089] There 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 the Fig. 6 . The organizational chart of the 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 on the Fig. 1C .

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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 needs to store a new sample in said measurement table.

[0095] 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, allowing the subsequent storage of captures and metrics relating to data traffic measurements of said communication tunnel.

[0096] Then, step 705 is performed.

[0097] 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.

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

[0099] In a particular embodiment, when the network probe has an upstream probe role (i.e., network probe upstream of the communication tunnel in question for the direction of communication considered), each table entry includes: a timestamp information field as contained in the flag packet that caused the entry in the metrics table to be created; a sequence number field as contained in the flag packet that caused the entry in the metrics table to be created; a data count field transiting the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0100] And when the network probe has a downstream probe role (i.e., network probe downstream of the communication tunnel in question for the considered communication direction), each table entry includes: a timestamp information field as contained in the flag packet that caused the entry in the metrics table to be created; a timestamp information field marking the instant at which the flag packet, which caused the entry in the metrics table to be created, was received (capture timestamp); a sequence number field as contained in the flag packet that caused the entry in the metrics table to be created; a data count field transiting through the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0101] In another particular embodiment, the table entries have the same format regardless of the role, upstream or downstream, of the probe in question, namely: a timestamp information field as contained in the flag packet that caused the entry in the metrics table to be created; a timestamp information field marking the instant at which the flag packet, which caused the entry in the metrics table to be created, was captured (whether upstream or downstream of the communication tunnel, depending on the direction of communication to which the metrics table in question applies); a sequence number field as contained in the flag packet that caused the entry in the metrics table to be created; a data count field transiting through the communication tunnel, for the direction of communication considered (for the type of service to which the flag packet corresponds, if applicable).

[0102] 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 the Fig. 8 .

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

[0104] For each sample, column 801 contains a sample Idx index value in the metrics 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 metrics 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).

[0105] 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.

[0106] For each sample, column 803 contains FTS timestamp information as contained in the flag packet that caused the entry corresponding to the Idx index value in question to be created in the measurement table.

[0107] 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 Idx index value in question was captured.

[0108] 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).

[0109] 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).

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

[0111] An 811 line stores a sample, with index value Idx equal to 0, including: the sequence number Seq is equal to 38; the timestamp information contained in the corresponding flag packet has a value X0 which is equal to X, where X is a reference instant; 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 instant X0 when the flag packet in question was transmitted.

[0112] An 812 line stores a sample, with index value Idx equal to 1, including: the sequence number Seq is equal to 39; the timestamp information contained in the corresponding flag packet has a value X1 which is equal to X+TS, where TS is a fixed predefined value of the flag packet timing period; the capture timestamp information of the corresponding flag packet has a value X'1 which is equal to X1+L1, where L1 is a capture latency duration relative to the instant X1 when the flag packet in question was transmitted.

[0113] A line 814 stores a sample, with index value Idx equal to 255, including: the sequence number Seq is equal to 293; the timestamp information contained in the corresponding flag packet has an X255 value which is equal to X+255*TS; the capture timestamp information of the corresponding flag packet has an X'255 value which is equal to X255+L255, where L255 is a capture latency duration relative to the X255 instant when the flag packet in question was transmitted.

[0114] 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: row 811 contains in column 805 a QoP0 packet count measurement, and in column 806 a QoB0 byte count measurement; row 812 contains in column 805 a QoP1 packet count measurement, and in column 806 a QoB1 byte count measurement; and row 814 contains in column 805 a QoP255 packet count measurement, and in column 806 a QoB255 byte count measurement.

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

[0116] Note that, because flag packets may be lost, it is possible for two successive samples in the measurement table to have sequence numbers that are not consecutive. This situation occurs particularly downstream of the communication tunnel, when congestion on the path taken by the communication tunnel has caused packet losses.

[0117] Back to the Fig. 7 , step 708 is performed, where the algorithm is terminated.

[0118] 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 caused 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 caused 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.

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

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

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

[0122] The sampling histories on both sides 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 monitoring the same communication tunnel, or the orchestrator 180, to collect these sampling histories, or information derived therefrom by calculations, on both sides of the communication tunnel, in order to evaluate possible congestion situations.

[0123] In a particular embodiment, one of the network probes (typically the network probe upstream of the communication tunnel, in a considered communication direction) requests 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 to do this within the framework of the inter-probe protocol. Preferably, the request comprises 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 comprises 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.

[0124] When a network probe receives a MeasReq request from its peer on the other side of the tunnel, the network probe determines which sampling history interval is affected by the request. The network probe then retrieves the requested sampling history from memory. If due to packet loss (e.g., loss of packet flag 2 in the Fig. 6 ), the sampling history available in memory of said probe does not correspond to the requested sampling history, then the network probe retrieves in memory the sampling history closest to the requested sampling history and transmits it, or information derived from it by calculations, 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.

[0125] For example, by relying on the Fig. 6 , a MeasReq 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.

[0126] There Fig. 9 schematically illustrates a network probe collaboration flowchart

[0127] P1 901 and P2 902 for evaluating a congestion situation in a communication tunnel, in a first embodiment.

[0128] In a step 910, the network probe P1 901, upstream of the communication tunnel, sends a MeasReq request to the probe P2 902, downstream of the communication tunnel. The MeasReq request is of type MeasReq1, 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 probe P2 902 in view of the sampling history stored by the probe P2 902 with respect to said type(s) of service specified in the MeasReq request in the communication tunnel in question.Unless implicit in the inter-probe protocol, the MeasReq request indicates which communication tunnel is affected, and which direction of communication is also affected (e.g., by specifying a source 120 endpoint address and a destination 120 endpoint address).

[0129] 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.

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

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

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

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

[0134] In a step 914, the P2 network probe 902 performs latency, jitter and volume calculations, for each type of service required. Referring to the Fig. 8 , the P2 902 network probe uses the difference between column 804 and column 803. Preferably, the P2 902 network probe calculates: the minimum transit latency of the flag packets of the sequence number interval considered; the maximum transit latency of the flag packets of the sequence number interval considered; the average transit latency of the flag packets of the sequence number interval considered; the minimum jitter experienced by the flag packets of the sequence number interval considered; the maximum jitter experienced by the flag packets of the sequence number interval considered; the average jitter experienced by the flag packets of the sequence number interval considered; the data transit volume (quantity of packets, bytes, etc.) in the communication tunnel over the sequence number interval considered.

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

[0136] The P2 902 network probe adds the following retrieved information to the MeasResp response, for each type of service required: the sequence number interval actually considered; 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.

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

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

[0139] In a step 917, the network probe P1 901 calculates a possible loss of data volume (of packets, bytes, etc.) over the sequence number interval actually considered by the network probe P2 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 network probe P1 901 with respect to its own sampling history, over the sequence number interval actually considered by the network probe P2 902, and the volume transmitted by the network probe P2 902 in the MeasResp response.

[0140] 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 flag packets between two successive measurements has occurred. In this case, the latency and jitter values ​​transmitted by the P2 902 network probe are not taken into account by the P1 901 network probe. The P1 901 network probe then calculates an approximate value of the data volume loss.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 S1 = S2-1 accumulates the volume of packets not lost on the way which were transmitted between the flag packet with sequence number S1 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 S1 and the flag packet with sequence number S2).Thus, by considering two successive MeasResp responses, the network probe P1 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.

[0141] In a step 918, the network probe P1 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 network probe P1 901 stores the sequence number Seq of the last flag packet received and the current volume, as indicated by the network probe P2 902 in the MeasResp response.

[0142] In a step 919, using the latency and jitter information transmitted by the network probe P2 902 and the calculation of possible loss of data volume in step 917, the network probe P1 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. Using this congestion situation evaluation, the network probe P1 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 network probe P1 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.

[0143] Performing latency, jitter, and volume calculations at the receiving end allows the MeasResp message to be small compared to sending raw measurements. Thus, the inter-probe protocol has a reduced cost in terms of bandwidth consumption.

[0144] 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 the Fig. 10 .

[0145] There 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).

[0146] 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 a source endpoint 120 address and a destination endpoint 120 address).

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

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

[0149] 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 based on 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.

[0150] 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).

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

[0152] The P4 1002 network probe preferentially includes in the MeasResp response the following retrieved information, for each type of service required: the sequence number interval actually considered; 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.

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

[0154] 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).

[0155] In a step 1016, the P3 network probe 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 P3 network probe 1001 can perform the same calculations as the P2 network probe 902 in step 914. Thus, preferably, the P3 network probe 1001 calculates: the minimum transit latency of the flag packets of the sequence number interval considered; the maximum transit latency of the flag packets of the sequence number interval considered; the average transit latency of the flag packets of the sequence number interval considered; the minimum jitter experienced by the flag packets of the sequence number interval considered; the maximum jitter experienced by the flag packets of the sequence number interval considered; the average jitter experienced by the flag packets of the sequence number interval considered; the data transit volume (quantity of packets, bytes, etc.) in the communication tunnel over the sequence number interval considered.

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

[0157] 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 P3 1001 network probe. The P3 1001 network probe then calculates an approximate value of the data volume loss, as already explained above in relation to the 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.

[0158] 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.

[0159] 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 data transmission profiles in the communication network(s) 100a so as to take into account, preferentially improve (e.g., service admission management), the congestion situations that 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.

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

[0161] In a particular embodiment applicable to the algorithms of the 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 carried out 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 carried out 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.Since 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 possible loss of volume of data 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).

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

[0163] A particular hybrid embodiment compared to the algorithms of the Figs. 9 And 10can also be implemented. The volumetric calculation is then performed by the downstream network probe, and the latency and jitter calculations are performed by the upstream network probe. To do this, the MeasResp response is of type MeasResp3. The MeasResp response then includes the sequence number Seq and timestamp information, but not the data volume information. In relation to the 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 may, however, also include 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. This makes it possible to find a compromise in bandwidth consumption by the inter-probe protocol, while maintaining the accuracy of the latency and jitter calculation results.

Claims

1. 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 end-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 end-point (120) of the first router (110), each network probe being configured to take data rate measurements of data entering a communication tunnel between the first end-point (120) and the second end-point (120) and exiting said communication tunnel, the method comprising the following steps within the context of monitoring traffic in the communication tunnel: - periodically injecting, by way of the first network probe, in parallel with the traffic of the communication tunnel, flag packets delimiting time periods over which the data rate measurements are made, each flag packet including timestamp information expressing an injection time reference for said flag packet, and each network probe having access to the data plane of the router associated therewith in order to be able to inject the flag packets in order to time the data rate measurements in the communication tunnel and to capture the volume of packets transmitted in the communication tunnel and the flag packets related thereto; - gathering information relating to a timing variation of a data stream in the communication tunnel, the timing variation of a data stream being measured thanks to a difference between the timestamp information contained in the flag packets and timestamp information relating to an instant at which said flag packets were captured by the second network probe; - assessing possible congestion situations experienced by the communication tunnel as a function of said gathered information.

2. Method according to Claim 1, comprising the following step: - computing a possible loss of data volume in the communication tunnel, by comparing a data volume count at the output of the communication tunnel between successive flag packets, detected by the second network probe, with a data volume count 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, wherein the flag packets are UDP type packets sent on a port dedicated to said flag packets.

4. Method according to any one of Claims 1 to 3, wherein the flag packets are injected for each type of service from among a plurality of types of service conveyed by the communication tunnel.

5. Method according to any one of Claims 1 to 4, wherein the flag packets are injected into a user plane upstream of the first end-point relative to the communication tunnel.

6. Method according to any one of Claims 1 to 5, wherein, in order to gather the information relating to a timing variation of a data stream in the communication tunnel, at least the second network probe comprises at least one measurement table for storing a sampling log 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 counting field for counting data passing through 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. Method according to Claim 6, wherein the first network probe transmits a request to the second network probe requesting to transmit in response information derived from computations of a sampling log of the flag packets received by the second network probe, the request involving a range of sequence numbers to be considered, the computations being intended to assess possible congestion situations and including: - a minimum transit latency of the flag packets of said range of sequence numbers; - a maximum transit latency of the flag packets of said range of sequence numbers; - an average transit latency of the flag packets of said range of sequence numbers; - a minimum jitter level experienced by the flag packets of said range of sequence numbers; - a maximum jitter level experienced by the flag packets of said range of sequence numbers; - an average jitter level experienced by said range of sequence numbers; - a volume of data passing through the communication tunnel over said range of sequence numbers.

8. Method according to Claim 6, wherein the first network probe transmits a request to the second network probe requesting to transmit in response all or some of the sampling log of the flag packets received by the second network probe, the first network probe then carrying out computations intended to assess possible congestion situations and including: - a minimum transit latency of the flag packets of said range of sequence numbers; - a maximum transit latency of the flag packets of said range of sequence numbers; - an average transit latency of the flag packets of said range of sequence numbers; - a minimum jitter level experienced by the flag packets of said range of sequence numbers; - a maximum jitter level experienced by the flag packets of said range of sequence numbers; - an average jitter level experienced by said range of sequence numbers; - a volume of data passing through the communication tunnel over said range of sequence numbers.

9. Method according to any one of Claims 1 to 8, wherein the first network probe comprises at least one further measurement table for storing a sampling log of flag packets captured at the input of the communication tunnel, with each entry of this further 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 counting field for counting data passing through 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.

10. Method according to Claim 9, wherein the first network probe computes 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 with the capture timestamp information of the flag packets captured by said first network probe.

11. Method according to Claim 10, wherein the first network probe further estimates a possible loss of data volume that is related to the quality of service of the first router, from detecting losses of flag packets injected by the first network probe.

12. 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 end-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 end-point (120) of the first router (110), each network probe being configured to take data rate measurements of data entering a communication tunnel between the first end-point (120) and the second end-point (120) and exiting said communication tunnel, the communication system comprising electronic circuitry configured to carry out the following steps within the context of monitoring traffic in the communication tunnel: - periodically injecting, by way of the first network probe, in parallel with the traffic of the communication tunnel, flag packets delimiting time periods over which the data rate measurements are made, each flag packet including timestamp information expressing an injection time reference for said flag packet, and each network probe having access to the data plane of the router associated therewith in order to be able to inject the flag packets in order to time the data rate measurements in the communication tunnel and to capture the volume of packets transmitted in the communication tunnel and the flag packets related thereto; - gathering information relating to a timing variation of a data stream in the communication tunnel, the timing variation of a data stream being measured thanks to a difference between the timestamp information contained in the flag packets and timestamp information relating to an instant at which said flag packets were captured by the second network probe; - assessing possible congestion situations experienced by the communication tunnel as a function of said gathered information.