METHOD FOR DETERMINING THE BANDWIDTH OF A COMMUNICATION LINK

Abstract

A method for determining bandwidth on a communication link between a first endpoint, with which a first network probe is associated, and a second endpoint, with which a second network probe is associated, is described. Flag packets are injected (403), by the first network probe, to provide time markers. Time stamp information for capturing the flag packets is collected by the second network probe, as well as measurements (405) of data volume output from the communication link. Padding traffic is injected (404) by the first network probe so as to create a congestion situation on the communication link during a test period. Thus, by determining what bandwidth is consumed during the test period, the bandwidth of the communication link is determined (408). Figure to be published with the abstract: Fig. 4

Description

Title of the invention: METHOD FOR DETERMINING THE BANDWIDTH OF A COMMUNICATION LINK Technical field

[0001] The present invention relates to a method for determining the bandwidth of a communication link using network probes which monitor traffic passing through the communication link in a communication network, 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, 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] A difficulty lies in the exact determination of the bandwidth of these communication networks. Indeed, the bandwidth actually available in a communication network may be lower than the bandwidth theoretically available in this communication network, in particular because of environmental hazards. It is known in particular that a variation in meteorological environmental conditions can affect the bandwidth available on a satellite or optical communication link, or that a variation in electromagnetic environmental conditions can affect the bandwidth available on an unshielded communication cable.

[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 for determining bandwidth on a communication link on which a data stream is transported between a first termination point at the input of the communication link, with which a first network probe is associated, and a second termination point at the output of the communication link, with which a second network probe is associated, the method comprising the following steps:

[0008] - periodically inject, by the first network probe, flag packets on the communication link, the flag packets providing time markers to the data flow on the communication link;

[0009] - collecting capture timestamp information of said flag packets by the second network probe and data volume information output from the communication link;

[0010] - inject, by the first network probe, stuffing traffic so as to create a congestion situation on the communication link during a test period;

[0011] - determining what bandwidth is consumed during the test period; and

[0012] - determining the bandwidth of the communication link as said band bandwidth consumed.

[0013] Thus, due to the congestion situation on the communication link which is created by the stuffing traffic, the capacity of the communication link is used to the maximum, and the bandwidth consumed is equal to the bandwidth of the communication link.

[0014] According to a particular embodiment, the communication link is a communication tunnel in a wide area communication network.

[0015] According to a particular embodiment, the data stream transported by the communication link comprises data sub-streams having distinct service types.

[0016] According to a particular embodiment, the flag packets are injected for each type of service among said distinct types of service.

[0017] According to a particular embodiment, the stuffing traffic has a dedicated service type.

[0018] According to a particular embodiment, the type of service dedicated to stuffing traffic is associated with the lowest priority among said distinct types of service.

[0019] According to a particular embodiment, the consumed bandwidth is calculated for each type of service among said distinct types of service, and the bandwidth of the communication link is obtained by summing the consumed bandwidth calculated for each type of service.

[0020] According to a particular embodiment, to collect the timestamp information capture and volumetric information, the second network probe comprises at least one measurement table for storing a history of sampling of flag packets captured at the output of the communication tunnel, each entry in the measurement table corresponding to a sample comprising:

[0021] - a timestamp information field marking the instant at which the flag packet corresponding to the sample in question was captured;

[0022] - a sequence number field as contained in the cor flag packet corresponding to the sample in question; and

[0023] - a data counting field transiting over the communication link between the flag packet corresponding to the sample in question and the flag packet corresponding to the next sample in the measurement table.

[0024] According to a particular embodiment, the first network probe transmits to the second network probe a request requiring the transmission in response of consumed bandwidth information which is derived by calculations of a sampling history of the flag packets received by the second network probe, the request including information on the interval of sequence numbers of flag packets to be considered to define said history over the test period.

[0025] According to a particular embodiment, when due to packet losses, the sampling history available in memory of the second probe does not correspond exactly to the sampling history requested by the query, the second network probe finds in memory a sampling history closest to the requested sampling history, and indicates in response to the query which interval of flag packet sequence numbers was actually found.

[0026] Also proposed here is a communication system comprising a communication link on which a data stream is transported between a first termination point at the input of the communication link, with which a first network probe is associated, and a second termination point at the output of the communication link, with which a second network probe is associated, the system comprising electronic circuitry configured to perform a bandwidth determination by:

[0027] - periodically injecting, by the first network probe, flag packets on the communication link, the flag packets providing time markers to the data flow on the communication link;

[0028] - collecting capture timestamp information of said flag packets by the second network probe and data volume information output from the communication link;

[0029] - injecting, by the first network probe, stuffing traffic so as to create a congestion situation on the communication link during a test period;

[0030] - determining what bandwidth is consumed during the test period; and in

[0031] - determining the bandwidth of the communication link as said band bandwidth consumed. Brief description of the drawings

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

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

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

[0035] [Fig.2] schematically illustrates a connection of network probes with an or- chestrator;

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

[0037] [Fig.4] schematically illustrates a band determination flowchart passing through a communication tunnel;

[0038] [Fig.5] schematically illustrates a variation in data flow timing in a communication tunnel;

[0039] [Fig.6] schematically illustrates a variation in the timing of two sub-flows of data in the communication tunnel, with the presence of stuffing traffic;

[0040] [Fig.7] schematically illustrates a creation and update flowchart one or more measurement tables storing volumetric information of traffic in the communication tunnel;

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

[0042] [Fig.9] schematically illustrates cooperation between upstream network probes and downstream of the communication tunnel to determine available bandwidth for the communication tunnel.

[0043] DETAILED DESCRIPTION OF EMBODIMENTS

[0044] The detailed description is presented in the context of bandwidth determination in the context of using a communication tunnel in a WAN (Wide Area Network). The bandwidth determination is carried out more generally on a communication link, such as for example a satellite link, the termination points of which are equipped with network probes as described below.

[0045] [Fig.lA] schematically illustrates a communication system in which the present invention may be used.

[0046] The communication system comprises a plurality of routers 110. Three routers RI to R3 are shown, for illustrative 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.

[0047] 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 wide area network type, are shown for illustration purposes in [Fig.1A].

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

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

[0050] 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, because of its lower security level than the red networks). 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.

[0051] The communication system is equipped with network probes. Network probes are devices arranged and configured to perform measurements of data flow entering the communication tunnels and data exiting 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.

[0052] 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 pace 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.

[0053] 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 carry out bandwidth evaluations in the communication network(s) 100a. These bandwidth evaluations make it possible, if necessary, to adjust the admission of services in the communication network(s) 100a (i.e., accept / reject / close / modify / redirect communications in the communication network(s) 100a).

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

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

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

[0057] The capture module 155 includes a recovery 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 recovery 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 recovery 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. The capture module 155 can thus be seen as two specialized capture points per endpoint 120.

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

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

[0060] The injector 150 is configured to generate and transmit the flag packets on demand, for example 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. in time.

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

[0062] Each flag packet includes a sequence identifier (Seq). Each flag packet is thus numbered.

[0063] In a particular embodiment, each flag packet further includes timestamp information expressing a time reference for injection of said flag packet. This makes it possible, by jointly analyzing times of capture of the flag packets at the other end of the communication tunnel, to evaluate congestion situations.

[0064] The injector 150 is further adapted and configured to inject padding traffic in addition to the traffic of the supervised communication tunnel (outgoing traffic), i.e. when the network probe in question is associated with the termination point 120 at the input of the communication tunnel. The injection of the padding traffic into the communication tunnel is temporary and makes it possible to temporarily force the creation of a congestion situation, which will make it possible, thanks to an analysis of the aforementioned flag packets, to carry out an evaluation of the bandwidth actually available.

[0065] In a particular embodiment, the stuffing traffic consists of successive packets spaced apart by a potentially configurable fixed period of time.

[0066] In a particular embodiment, the packets of the stuffing traffic are UDP type packets sent on a port dedicated to said stuffing traffic. Thus, the packets of the stuffing traffic can be easily captured and distinguished from other packets by the network probes.

[0067] In a particular embodiment, the stuffing traffic has a dedicated, low-priority type of service value (e.g., DSCP field value), such that the stuffing traffic is primarily impacted when packet losses occur in congestion situations. Note that, in this case, an injection of flag packets specifically for this stuffing traffic is performed by the injector 150.

[0068] In a particular embodiment, the service type value (eg, DSCP field value) dedicated to the stuffing traffic has the lowest priority among said service types transported by the communication tunnel.

[0069] In a particular embodiment, during a period when the injection of traffic When padding is enabled, the injection of the very first packet of the padding traffic is synchronized with the injection of a flag packet of the same type of service (eg, DSCP field value) as that of the padding traffic. Thus, the bandwidth estimation carried out subsequently is more accurate.

[0070] In a particular embodiment, the temporary injection of the stuffing traffic is triggered upon receipt of a trigger request from an operator or the orchestrator 180, for example via the application module 165. The trigger request may comprise parameters of duration, rate, and type of service (eg, DSCP field value), the size of packets to be applied to the stuffing traffic.

[0071] Alternatively, the temporary injection of the stuffing traffic is triggered periodically. The trigger period, the injection duration, the injection rate, the type of service (eg, DSCP field value) dedicated to the stuffing traffic, the packet size of the stuffing traffic can be configured in advance by an operator, for example via the application module 165 and / or the network probe manager 160.

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

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

[0074] In a particular embodiment, each network probe has an address (typically, an IP address), for communicating in the communication network(s) 100a, which is predefined with respect to the address of the termination point 120 of the communication tunnel 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 (e.g., established). This also makes it possible to automatically configure the detection of 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. Thus, in particular the flag packets transmitted are easily identified by the remote network probe associated with the termination point 120 of the other side of the monitored communication tunnel. And the same mechanism applies for defining the addresses of other network probes in the communication system.

[0075] 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: application of a predefined conversion rule (“mapping” in English) from the address of the termination point 120 with which said network probe is associated, or application of a predefined offset (positive or negative) with respect to the address of the termination point 120 with which said network probe is associated, or addition of a unit to the address of the termination point 120 with which said network probe is associated.

[0076] In an alternative embodiment, the network probes have addresses independent of the addresses of the termination points 120 of the communication tunnel. Optionally, the injectors 150 have addresses of their own. Then, upon discovery of a communication tunnel, the network probe in question notifies its addressing plan to the remote network probe.

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

[0078] The application module 165 is responsible for collecting timestamp information of the instant of capture of said flag packets and measurements of the volume of data transmitted in the communication tunnel between the flag packets. The application module 165 is thus able to perform calculations on said measurements in order to determine information on available bandwidth. The measurements are carried out by a network probe downstream of the communication tunnel, and the calculations can be carried out by the application module 165 of this same network probe, or by the application module 165 of the network probe upstream of the communication tunnel after having obtained information representative of said measurements from the network probe downstream of the communication tunnel, or even by the orchestrator 180 after having obtained information representative of said measurements from the network probe downstream of the communication tunnel.

[0079] The application module 165 may also be 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 timestamp information contained in the flag packets and timestamp information of the instant of capture of said flag packets. The application module 165 is thus able to perform calculations on said measurements in order to evaluate congestion situations.

[0080] 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 information on bandwidth actually available, and possibly information on congestion situation, which would be revealed by the calculations which result from the measurements carried out.

[0081] Alternatively, the application module 165 is responsible for sending back to the orchestrator 180 information relating to the measurements carried out or the calculations resulting therefrom, the orchestrator 180 then being responsible for carrying out the appropriate service admission. Thus, 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 the calculations resulting therefrom can thus be shared with the orchestrator 180, in particular in order to determine information on the bandwidth available in the communication network(s) 100a and thus to 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 available bandwidth information which has thus been determined.

[0082] [Fig.3] schematically illustrates an example of network probe hardware architecture, making it possible in particular to implement the modular architecture of [Fig.1B].

[0083] 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 reader of storage medium, such as an SD (Secure Digital) card reader; a set of input and / or output interfaces, such as communication interfaces 305, enabling 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 packets, in particular flag packets and stuffing traffic, as described in more detail below, as well as to communicate with other network probes of the communication system or with the orchestrator 180.

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

[0085] 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" in English), such as an FPGA (for "Field-Programmable Gate Array" in English) or an ASIC (for "Application-Specific Integrated Circuit" in English).

[0086] It follows that the modular architecture of [Fig.lB] 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.

[0087] 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 [Fig.lB].

[0088] It should be noted that the orchestrator 180 may also comprise, in a similar manner, electronic circuitry arranged and configured to implement the steps and behaviors described here in relation to said orchestrator 180, and in particular steps of calculating available bandwidth, or even evaluating congestion situations, from measurements carried out by said network probes.

[0089] [Fig.4] schematically illustrates a flowchart for determining the bandwidth of a communication tunnel whose endpoints 120 are monitored by respective network probes.

[0090] In a step 401, each aforementioned network probe detects the communication tunnel communication (for example, a newly created communication tunnel). The detection of a communication tunnel is preferably carried out by detecting the transmission of a tunnel encapsulation packet, for example of the GRE, mGRE or IPSec type. The communication tunnel is identified by a source address and a destination address which form the pair of termination points 120 of the communication tunnel, for the direction of communication considered.

[0091] In a step 402, the network probes on either side of the communication tunnel set up the inter-probe communication protocol, as already mentioned. The network probes are thus able to communicate with each other and / or with the orchestrator 180, in order to cooperate for the determination of bandwidth available for the communication tunnel.

[0092] Preferably, each network probe opens a network connector (“socket” in English) with its address (IP) and 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 (or by the orchestrator 180), to this address and this dedicated UDP port. As already mentioned, other addressing plan sharing approaches can be implemented.

[0093] In a step 403, a first network probe, on the upstream side of the communication tunnel relative to the communication direction for which the bandwidth is to be determined, instantiates an injector configured to inject flag packets as well as padding traffic. The flag packets thus define a reference clock in the communication direction for which the available bandwidth is to be determined.

[0094] Preferably, each network probe on either side of the communication tunnel instantiates such an injector. Thus, a reference clock is established in both directions of communication between the network probes via the communication tunnel, which makes it possible to determine the bandwidth in each direction of communication, which is particularly advantageous in the case of an asymmetrical communication link.

[0095] Then, when the injector of the first network probe is instantiated, in this step 403, the first network probe triggers the injection of flag packets by said injector, including for the type of service (eg, DSCP field value) intended for stuffing traffic, as already mentioned above.

[0096] And, in a step 404, the first network probe triggers the injection of padding traffic, as already mentioned above.

[0097] Then, in a step 405, the second network probe, at the other end of the communication tunnel, i.e. downstream side with respect to the direction of communication for which the bandwidth must be determined, performs data volume captures and measurements for the communication tunnel in question. The measurements of vo Data luminosity is achieved by counting the volume of data transmitted between successive flag packets, detected in the outgoing traffic of the communication tunnel.

[0098] The data volume measurements are preferably carried out by type of service in the communication tunnel, for example by relying on information on the type of service (eg, DSCP field value) included in the encapsulation packets of the communication tunnel, as well as in the flag packets associated with this same type of service.

[0099] As detailed below, the flag packets serve as a clock reference for performing volumetric measurements and thus determining the bandwidth available for the communication tunnel.

[0100] The flag packets can further serve as a clock reference to determine timing variations between the entry and exit of the communication tunnel, as schematically illustrated in [Fig.5] and thus evaluate congestion situations (typically, other than those deliberately created through stuffing traffic).

[0101] In a particular embodiment, the data volume measurements transmitted in the communication tunnel between flag packets detected successively at the output of the communication tunnel are stored in a measurement table, as detailed below in relation to Figs. 7 and 8.

[0102] In a step 406, when the period during which the insertion of the stuffing traffic is judged sufficient to carry out a bandwidth estimation, the network probe upstream of the communication tunnel stops the injection of the stuffing traffic.

[0103] Then, in a step 407, the network probe upstream of the communication tunnel stops the injection of the flag packets. The injection of the flag packets can however be maintained well beyond the injection of the padding traffic (for example, permanently) in order to make it possible to detect congestion situations which would occur despite the absence of padding traffic. Indeed, if the timing at the output of the communication tunnel differs from the timing at the input of the communication tunnel beyond a predetermined margin, a congestion situation is detected, as detailed below in relation to [Fig.5]. A service admission adjustment can be carried out accordingly.

[0104] In a step 408, one of the network probes on either side of the communication tunnel, or the orchestrator 180, performs a bandwidth calculation from the volumetric measurements carried out in step 405. The bandwidth available for the communication tunnel is the bandwidth consumed during the test period. Thus, according to this calculation, the bandwidth corresponds to the volume V of data transmitted in the communication tunnel over a period, delimited by first and second flag packets received at the output of the communication tunnel, during which the padding traffic was injected. In other words, the bandwidth is given by this volume V divided by the time difference between the instant of capture of said first flag packet and the instant of capture of said second flag packet, at the output of the communication tunnel.

[0105] In a particular embodiment, when the communication tunnel transports data sub-flows having distinct service types, the available bandwidth BDW for the communication tunnel is calculated as being the sum of the bandwidths consumed individually by the sub-flows in question, i.e.:

[0106] BDW = Yi(VJ AfJ

[0107] where: - i represents an index on the sub-flows (or service types); - U, is the volume of data transmitted for the sub-flow identified by the index value i during the time period A; and - A tj is the duration of the test period for the sub-flow identified by the index value i.

[0108] An illustrative example is presented below in relation to [Fig.6].

[0109] Furthermore, a particular embodiment of cooperation between network probes in order to carry out the bandwidth calculation is presented below in relation to [Fig.9].

[0110] [Fig.5] schematically illustrates a variation in the timing of a data flow in a communication tunnel T.

[0111] At the input of the communication tunnel T, the data is transmitted (for example for a given type of service) according to a rate DR-tx. The injector 150 of the first network probe 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.

[0112] At the output of the communication tunnel T, 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. 5], Packet 2 was lost en route. The data stream therefore experienced a timing variation in the supervised communication tunnel T.

[0113] Thanks to the timestamp information contained in the flag packets, the second network probe (i.e., at the output of the communication tunnel T) is however able to determine the timing at the input of the communication tunnel T. 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 second network probe is able to determine the timing at the output of the communication tunnel.

[0114] By comparing the timing at the input of the communication tunnel T and the timing at the output of the communication tunnel T, the timing variation in the supervised communication tunnel T can be determined. Congestion situations can thus be detected, when the timing difference is greater than a predetermined margin threshold. Such congestion situations can be forced, using the padding traffic, in order to determine the bandwidth available for the communication tunnel. Thus, in the context of the invention, the flag packets are mainly used as markers to identify a test period during which the padding traffic is injected, in order to allow the bandwidth to be determined over this test period. An illustration is given in [Fig.6].

[0115] [Fig.6] schematically illustrates a variation in the timing of a data flow in a communication tunnel T for two types of service in parallel, with insertion of padding traffic.

[0116] At the input of the communication tunnel T, packets are transmitted for a first type of service (eg, first DSCP field value), according to a rate TXB for a first sub-flow of the communication tunnel T. The injector of the first network probe thus transmits, according to a fixed period TH, flag packets 1 to 8 for the first type of service. In parallel, packets are transmitted for a second type of service (eg, second DSCP field value), according to a rate TX2, for a second sub-flow of the communication tunnel T. The injector of the first network probe thus transmits, according to a fixed period T2, flag packets 5 to 9 for the second type of service.

[0117] The flag packets 1 to 8 relating to the first sub-flow of the communication tunnel T are therefore transmitted by the termination point 120 at the input of the communication tunnel T at respective times tfl to ti8 separated by a fixed period Tb. The fixed period Ti can be configurable. And the flag packets 5 to 9 relating to the second sub-flow of the communication tunnel T are transmitted by the termination point 120 at the input of the communication tunnel T at respective times t2l to t28 separated by a fixed period T2. The fixed period Ti can also be configurable.

[0118] At the output of the communication tunnel T, the packets of the first sub-flow of the communication tunnel T are received according to a rate RXi which typically differs from the rate TXi at the input of the communication tunnel T. The flag packets 1, 3, 4, 5, 6 and 8 relating to the first sub-flow of the communication tunnel T are then received by the termination point 120 at the output of the communication tunnel at respective times t'il, t' 13, t'i4, t' 15, t' 16 and t' 18. The flag packets 2 and 7 relating to the first sub-flow of the communication tunnel T (i.e., for the first type of service) were lost during transmission in the communication tunnel T.

[0119] In parallel, at the output of the communication tunnel T, the packets of the second sub-flow of the communication tunnel T are at a rate RX2 which typically differs from the rate TX2 at the input of the communication tunnel T. The flag packets 5, 7 and 8 relating to the second sub-flow of the communication tunnel T are received by the termination point 120 at the output of the communication tunnel at respective times t'25, t'27 and t'28. The flag packets 6 and 9 relating to the second sub-flow of the communication tunnel T (i.e., for the second type of service) were lost during transmission in the communication tunnel T.

[0120] It appears in [Fig.6] that the sub-flows of the communication tunnel T undergo different timing variations from one another, due to the fact that the associated service types are different.

[0121] Sets of flag packets can be used for each type of service. In which case, as illustrated in [Fig.6], the flag packets do not have to be synchronized from one sub-flow to another.

[0122] In addition to the flag packets, [Fig.6] illustrates the insertion of the padding traffic, in horizontal hatching at the entrance to the communication tunnel T.

[0123] By identifying the sequence number (Seq) of the very first flag packet injected during the test period (period of injection of the padding traffic), and the sequence number (Seq) of the very last flag packet injected during the test period, the second network probe, at the output of the communication tunnel T, is able to determine bounds which must actually be considered in the data flow of the communication tunnel T to carry out the bandwidth calculation. In the case of different sub-flows with series of flag packets dedicated to each sub-flow (and therefore to each type of service), these bounds must be determined independently for each type of service. In the example of [Fig.6], the subflow portion between flag packet 4 and flag packet 6 is examined for the first subflow of the communication tunnel T, and the subflow portion between flag packet 7 and flag packet 8 is examined for the second subflow of the communication tunnel T. The volume between these flag packets per type of service is then determined accordingly to determine the bandwidth consumed by each subflow. Then, the bandwidth available for the communication tunnel T is equal to the sum of the bandwidth consumed by each sub-flow.

[0124] Thus, [Fig.6] illustrates at the output of the communication tunnel T, by vertical hatching, that only the data volume Vi (average data volume) for the first type of service is considered between the flag packets 4 and 6 for the bandwidth calculation, and that only the data volume V2 (average data volume) for the second type of service is considered between the flag packets 7 and 8 for the bandwidth calculation.

[0125] [Fig.7] schematically illustrates a flowchart for creating and updating a measurement table storing information representative of volumetric measurements of data traffic in a communication tunnel, according to a timing defined by flag packets. The flowchart of [Fig.7] is executed by the network probe downstream of the communication tunnel.

[0126] In a step 701, the network probe in question obtains a data packet from the communication tunnel, as recovered by the capture module 165 from all the data packets transiting (transmission / reception) via the termination point 120 with which said network probe is associated.

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

[0128] In step 703, the network probe determines whether the data packet in question 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 data packet in question 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.

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

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

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

[0132] Then, step 705 is performed.

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

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

[0135] The measurement table is such that each table entry includes:

[0136] - 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);

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

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

[0139] In a particular embodiment, as already mentioned, the flag packets include timestamp information expressing a time reference for injection of said flag packet. Then, each table entry further includes:

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

[0141] 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]. The measurement table structure illustrated in [Fig.8] comprises six columns, referenced from 801 to 806.

[0142] 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 have been captured (in a rotating manner, i.e. when the entry with index value Idx equal to 255 is filled, the next entry to be manipulated is the one with index value Idx equal to 0).

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

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

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

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

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

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

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

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

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

[0152] - 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 XO when the flag packet in question was sent.

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

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

[0155] - 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;

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

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

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

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

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

[0161] 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 line 814 contains in column 805 a QoP255 packet count measurement, and in column 806 a QoB255 byte count measurement.

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

[0163] 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 when congestion on the path taken by the communication tunnel has caused packet losses.

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

[0165] In step 707, the network probe performs a count of the packets transiting in the communication tunnel, for the direction of communication considered. The received data packet is taken into account in the current sample in the corresponding table. For example, a number of packets received following the flag packet which has that resulted in the creation of the corresponding entry in the table is incremented by one. In addition, an amount 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 data packet in question. It should be noted that in doing so, flag packets are not included in the count. It is also possible to include flag packets in the count; in this case, step 706 is followed by step 707 and not by step 708.

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

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

[0168] 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 (typically, volumetric accumulation between two flag packets identified, by type of service). A MeasReq request is transmitted to do this within the framework of the inter-probe protocol. The MeasReq request then comprises a field indicating an interval of flag packet sequence numbers for which the history, or said information derived therefrom by calculations, must be provided in response. A particular embodiment is presented below in relation to [Fig.9].

[0169] [Fig.9] schematically illustrates a cooperation between upstream (PI network probe 901) and downstream (P2 network probe 902) network probes of a communication tunnel to determine an available bandwidth for the communication tunnel.

[0170] It is considered here that the injection of flag packets has already been previously activated.

[0171] And in a step 910, the network probe PI 901 begins injecting the padding traffic. A first padding packet Pad_l is thus transmitted in the communication tunnel. This first padding packet Pad_l, if it is not lost during its transmission in the communication tunnel, is detected (captured) at the output of the communication tunnel by the network probe P2 902 in a step 921.

[0172] The injection of the padding traffic may be triggered by the PI network probe 901 as a result of a predetermined event, for example according to a periodic trigger to periodically evaluate the available bandwidth, or for example upon detection of particular transmission conditions or variations in particular transmission conditions. Alternatively, the injection of the padding traffic may be triggered by instruction from the orchestrator 180 to the PI network probe 901.

[0173] Then, in a step 911, the network probe PI 901 continues the injection of the padding traffic resulting in the transmission in the communication tunnel of successive padding packets Pad_i (z being here an index). These padding packets Pad_i, if they are not lost during their transmission in the communication tunnel, are detected (captured) at the output of the communication tunnel by the network probe P2 902 in a step 922. The network probe P2 902 then carries out volumetric measurements, and records in a measurement table the volume of data received between successively received flag packets (see Figs. 7 and 8).

[0174] Finally, in a step 912, the network probe PI 901 terminates the injection of the padding traffic. The last padding packet, labeled Pad_n, is thus transmitted in the communication tunnel. This last padding packet Pad_n, if it is not lost during its transmission in the communication tunnel, is detected (captured) at the output of the communication tunnel by the network probe P2 902 in a step 923. The capture of the padding traffic is terminated, and the measurement table is updated accordingly by the network probe P2 902.

[0175] The injection of the stuffing traffic was such that a congestion situation was created, so that the consumed bandwidth is equivalent to the available bandwidth. The volumetric measurements recorded in the measurement table by the network probe P2 902, when the stuffing traffic was injected into the communication tunnel, then make it possible to determine the bandwidth available for the communication tunnel.

[0176] Then, in a step 930, the PI network probe 901 transmits a MeasReq request to the P2 network probe 902. The MeasReq request is received by the P2 probe 902 in a step 931.

[0177] Sending the MeasReq request may be triggered by the PI network probe 901 as a result of stopping the injection of the padding traffic (stopping the test period). Alternatively, sending the MeasReq request may be triggered by instruction from the orchestrator 180 to the PI network probe 901.

[0178] And in a step 932, the network probe P2 902 performs a search for a relevant time interval of data to be extracted from its measurement history stored in its measurement table.

[0179] Preferably, the MeasReq request includes information indicating a sequence interval of flag packets relevant for the calculation of consumed bandwidth.

[0180] In a particular embodiment, when several sub-flows corresponding to different respective service types are transported in the communication tunnel, the MeasReq request includes such information indicating a sequence interval of relevant flag packets for each sub-flow in question.

[0181] In a particular embodiment, when several sub-flows corresponding to different respective service types are transported in the communication tunnel and the stuffing traffic is associated with a dedicated service type, the MeasReq request includes such sequence interval information only for said service type dedicated to the stuffing traffic. The applicable sequence intervals for the other service types are deduced therefrom by the network probe P2 902. The flag packets relevant for the other service types are such that the capture timestamp information of these flag packets are included in the time interval defined by the capture timestamp information of the flag packets relevant for said service type dedicated to the stuffing traffic.

[0182] In an alternative embodiment, when the stuffing traffic is associated with a dedicated service type, the network probe P2 902 itself searches for the relevant flag packet sequence interval for the calculation of consumed bandwidth, this interval then being delimited by flag packets received between the instant of detection of the stuffing traffic and the instant of detection of stopping of the stuffing traffic.

[0183] When a network probe receives a MeasReq request from its counterpart 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.

[0184] If due to packet losses (eg, loss of packet flag 2 in [Fig.6]), the sampling history available in memory of said probe does not exactly correspond to a 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 therefrom by calculation, in a 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.

[0185] Thus, in a step 933, thanks to the volumetric information stored in the measurement table, the bandwidth consumed can be determined, as already described above.

[0186] Preferably, the bandwidth consumed is determined by type of service. And by summing the bandwidths consumed for the types of service transported in the communication tunnel, the available bandwidth, i.e. the (current) capacity of the communication link (eg, communication tunnel) is obtained in a step 934.

[0187] Then, in a step 935, the network probe P2 902 transmits a MeasResp response (in response to the MeasReq request) to the network probe PI 901. The MeasResp response is received by the PI probe 901 in a step 936.

[0188] In the presence of the orchestrator 180, the response MeasResp can be sent by the network probe P2 902 to the orchestrator 180 (for example, in the case where the request MeasReq was transmitted by the network probe PI 901 on instruction from the orchestrator 180).

[0189] The calculations of consumed and available bandwidth can be carried out, alternatively, by the network probe PI 901 or by the orchestrator 180. The network probe P2 902 provides for this purpose the relevant volumetry history, extracted from the measurement table.

[0190] Once the actual available bandwidth is determined, a service admission policy adjustment can then possibly be made accordingly.

Claims

Claims

1. Method for determining bandwidth on a communication link on which a data stream is transported between a first termination point (120) at the input of the communication link, with which a first network probe is associated, and a second termination point (120) at the output of the communication link, with which a second network probe is associated, the method comprising the following steps: - injecting (403) periodically, by the first network probe, flag packets onto the communication link, the flag packets providing time markers to the data stream on the communication link; - collecting (405) timestamp information for capturing said flag packets by the second network probe and data volume information at the output of the communication link;- injecting (404), by the first network probe, stuffing traffic so as to create a congestion situation on the communication link during a test period; - determining which bandwidth is consumed during the test period; and - determining (408) the bandwidth of the communication link as being said consumed bandwidth.;

2. The method of claim 1, wherein the communication link is a communication tunnel in a wide area communication network.

3. A method according to claim 1 or 2, wherein the data stream carried by the communication link comprises sub-data streams having distinct service types.

4. The method of claim 3, wherein the flag packets are injected for each of said distinct service types.

5. The method of claim 3 or 4, wherein the stuffing traffic has a dedicated service type.

6. The method of claim 5, wherein the type of service dedicated to stuffing traffic is associated with the lowest priority among said distinct types of service.

7. A method according to any one of claims 3 to 6, wherein the consumed bandwidth is calculated for each type of service among said distinct service types, and the communication link bandwidth is obtained by summing the consumed bandwidth calculated for each service type.

8. Method according to any one of claims 1 to 7, in which, to collect the capture timestamp information and the volumetry information, the second network probe comprises at least one measurement table (800) 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 (804) marking the instant at which the flag packet corresponding to the sample in question was captured; - a sequence number field (802) as contained in the flag packet corresponding to the sample in question; and - a field (806) counting data transiting on the communication link between the flag packet corresponding to the sample in question and the flag packet corresponding to the following sample in the measurement table.

9. Method according to claim 8, in which the first network probe transmits (930) to the second network probe a request requesting to transmit in response (935) information on consumed bandwidth which is derived by calculations (934) of a sampling history of the flag packets received by the second network probe, the request including information on the interval of sequence numbers of flag packets to be considered to define said history over the test period.

10. The method of claim 9, wherein when due to packet losses, the sampling history available in memory of the second probe does not exactly match the sampling history requested by the query, the second network probe retrieves in memory a sampling history closest to the requested sampling history, and indicates in response to the query which interval of flag packet sequence numbers has actually been retrieved.

11. Communication system comprising a communication link on which a data stream is transported between a first termination point (120) at the input of the communication link, with which a first network probe is associated, and a second termination point (120) at the input of the communication link, with which a first network probe is associated, output of the communication link, with which a second network probe is associated, the system comprising electronic circuitry configured to perform a bandwidth determination by: - periodically injecting (403), by the first network probe, flag packets onto the communication link, the flag packets providing time markers to the data flow on the communication link; - collecting (405) timestamp information of capture of said flag packets by the second network probe and data volume information at the output of the communication link; - injecting (404), by the first network probe, stuffing traffic so as to create a congestion situation on the communication link during a test period; - determining what bandwidth is consumed during the test period; and - determining (408) the bandwidth of the communication link as being said consumed bandwidth.

Images