EP1743453A1 - Mesure de performance dans un reseau de transmission de paquets - Google Patents

Mesure de performance dans un reseau de transmission de paquets

Info

Publication number
EP1743453A1
EP1743453A1 EP05769213A EP05769213A EP1743453A1 EP 1743453 A1 EP1743453 A1 EP 1743453A1 EP 05769213 A EP05769213 A EP 05769213A EP 05769213 A EP05769213 A EP 05769213A EP 1743453 A1 EP1743453 A1 EP 1743453A1
Authority
EP
European Patent Office
Prior art keywords
packet
flow
terminal
packets
collection unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05769213A
Other languages
German (de)
English (en)
Inventor
Emile Stephan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1743453A1 publication Critical patent/EP1743453A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/142Network analysis or design using statistical or mathematical methods
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays

Definitions

  • the present invention relates to the field of telecommunications networks and more specifically to the field of metrology of packet transmission telecommunications networks.
  • Metrology in the literal sense of “measurement science”, is developing in different areas of networks such as characterization and modeling of traffic, traffic analysis, or even the optimization of quality of service and performance.
  • Network metrology is also used to improve the supervision of a network. Its main objective is to provide assistance for sizing a network and for diagnosing problems detected in a network.
  • the growing complexity of networks, and in particular that of the Internet leads to ignorance of traffic and conditions of use. It becomes more and more difficult to have a real control of the network and its behavior.
  • network traffic is made up of multiple packet streams.
  • a packet flow is defined as an exchange of data between two terminals of a network whose packets have common characteristics, in particular common characteristics of origin, destination and service.
  • metrology aims to determine measurements to be carried out on the traffic of the network studied in order to have a better knowledge of this traffic.
  • measures There are two main types of measures.
  • a first type is composed of measurements made on a flow of test packets. To carry out these so-called “active" measurements, a stream of test packets is transmitted, through the network studied, from a first transmitting terminal to a second receiving terminal.
  • a test packet has a specific format containing a first field indicating a time reference for sending the packet and a second field indicating the sequence number of the packet in the stream of test packets sent.
  • the receiving terminal determines a delay for transmitting a test packet from the sending terminal according to the first field of the packet.
  • the receiving terminal can also detect packet losses based on the second field of a test packet.
  • a test packet is a packet for which a transmission time reference is known and which it is known to distinguish from other reception packets in order to associate it with an arrival time reference or to determine whether it is lost. We can thus obtain performance characteristics of an “end-to-end” flow, that is to say on the complete path of the flow of test packets, from the transmitter to the receiver, and in particular measurements transmission delay between the two terminals, based on known time references for sending and receiving packets.
  • This first type of measurement therefore makes it possible to obtain performance measurements over a complete path of the flow of test packets, that is to say between the terminal emitting the flow and the terminal receiving the flow.
  • the measurements thus obtained relate to the test packets of a flow. They are therefore qualitatively precise.
  • a disadvantage of this type of measurement is that it only provides information relating to the ends of the flow of test packets. It is therefore impossible to obtain information on a segment of the complete path between two network devices or between a network device and one of the terminals. The information thus obtained is therefore geographically imprecise.
  • a second type of measurement is known carried out at the level of network equipment by an analysis of the flows which pass through it.
  • passive measurements can be carried out either by measurement units on board the network equipment, or by measurement units external to the network equipment (or even passive probes) dedicated to passive measurements. The latter generally have less information than the on-board measurement units. These measurement units listen to traffic flowing on the links between network equipment.
  • This type of passive measurement widely used in existing networks, makes it possible to obtain volume information by flow and by network equipment.
  • One drawback of this type of measurement is that it provides information relating to network equipment which are very difficult to correlate with other information relating to other network equipment. Consequently, even if it is however possible to obtain relatively precise geometric information by correlation on a given segment, such a correlation remains complex to implement, in particular in the case where the flows are sampled in order to analyze them.
  • Another drawback of this type of measurement is that it only provides volumetric information relating to the flow by network equipment, in particular the number of packets analyzed as well as the sum of the sizes of the packets analyzed for a given flow. Consequently, the information obtained by this type of measurement can turn out to be qualitatively insufficient and even unreliable, in particular in the case where the flows are sampled in order to analyze them.
  • qualitatively precise information that is to say relating to the packets of a flow, and geographically precise, that is to say relating to segments of the complete path of the flow in the existing networks.
  • network equipment refer to active network equipment, that is to say which fulfills an active processing function in the network, such as for example switches or routers.
  • An active processing function in the network can also be defined as opposed to a passive processing function fulfilled in particular by a measurement unit.
  • the present invention aims to propose a solution tending to satisfy these needs.
  • a first aspect of the invention proposes a measurement method in a data packet transmission network, in which a stream of data packets transmitted by a first terminal passes through at least one network equipment item with which a measurement unit is associated.
  • the first terminal generates a packet flow, comprising first and second state control packets session; the measurement unit analyzes said first and / or second packet of said flow, passing through the network equipment; the first terminal sends a description of transmitted packet flow comprising at least the number of packets transmitted to the collection unit; the flow measurement unit sends a description of the flow comprising at least one item of information indicating the number of packets analyzed to the collection unit; and the collection unit identifies each analyzed packet of the flow as a function of the flow description to correlate, packet by packet, said flow description and said packet flow description.
  • a second aspect of the invention proposes a measurement system comprising means arranged to implement the above method.
  • a third aspect of the invention provides a collection unit comprising means arranged to implement the above method. Thanks to these provisions, it is possible to obtain precise information geographically and qualitatively of the traffic on the transmission network studied. Other aspects, aims and advantages of the invention will appear on reading the description of one of its embodiments.
  • FIG. 1 is a diagram of a network architecture according to an embodiment of the invention
  • - Figure 2 illustrates a network measurement method according to an embodiment of the invention
  • - Figure 3 illustrates a method according to an embodiment of the invention in a network architecture based on a collection unit comprising a first and a second module
  • - Figure 4 illustrates a format of a TCP packet header.
  • the invention can be used in all fields of metrology applied to packet transmission networks.
  • the invention proposes to couple active measures and passive measures in order to take advantage of each of them.
  • FIG. 1 represents a network architecture comprising a measurement system according to an embodiment of the invention.
  • a terminal 11 and a terminal 12 are connected to the IP network 10.
  • the terminals 11 and 12 are suitable for generating test packet flows.
  • the IP network 10 includes equipment respectively referenced
  • the pieces of equipment 13, 15 and 16 are each provided with an on-board flow measurement unit.
  • the measurement units include a measurement export function.
  • the invention also covers a configuration in which the flow measurement unit is an external entity and listens for traffic passing over a transmission link between the network equipments. or a terminal and equipment.
  • the terminals 11 and 12 as well as the equipment comprising flow measurement units 13, 15 and 16 are connected to a collection unit 18.
  • This collection unit is intended to receive the various information exported by the measurement units and the terminals 11 and 12 in order to group and correlate them to provide precise information, relating to the test test packets and corresponding to specific segments. of full path of the stream, including performance information related to packet loss or packet transmission delay.
  • Terminals 11 and 12 can be fixed terminals. They can also be mobile terminals.
  • the flow measurement units on board the equipment 13, 15, 16 implement flow analysis functions of the kind of those being normalized called 'IPFIX' including one implementation is distributed by Cisco Systems, Inc. under the name "Netflow”.
  • An “IPFIX” type service is a global flow analysis service passing through packet transmission network equipment, in particular routers and switches of IP, ATM, Ethernet or even MPLS (for Multiple Protocol Lable Switch) type.
  • Such a service provides an analysis of the flows entering a piece of equipment. It is also suitable for accumulating statistical measurements relating to a given flow as well as for exporting these measurements asynchronously to a collection unit 18.
  • the export of measurements to the collection unit is preferably carried out by encoding data in order to to reduce the necessary bandwidth. Such an export of measurements can be carried out on the fly, upon expiration of a timer, or upon detection of an end of flow.
  • a measurement unit can also store these measurements so as to allow the collection unit 18 to download them.
  • the invention covers any other analysis function of a measurement unit providing flow information and any other method of exporting this flow information.
  • the network equipment provided with a flow measurement unit are routers.
  • the invention also covers a flow measurement system in which the network equipment provided with a flow measurement unit are other network equipment, such as for example switches.
  • a stream of test packets, transmitted by the terminal 11 to destination of the terminal 12 is identified by the following information: the IP address, noted T11_SrcAddr, and the logical port, noted T11_SrcPort, of the sending terminal 11; the IP address, noted T12_DstAddr, and the logical port, noted T12_DstPort, of the receiving terminal 12; the protocol used, noted Proto_test, for example TCP for "Transmission Control Protocol", UDP for "User Datagram Protocol", or even ICMP for "Internet Control Message Protocol".
  • a flow description preferably also includes a field for the numbers of administrative domains, or AS for “Autonomous System”, crossed, denoted respectively “SrcAS” and “DstAS”.
  • a measurement unit of a router stores data relating to the flows passing through this router. On receipt of a packet, the unit of measurement determines whether the packet belongs to a flow being analyzed. If it belongs to a flow being analyzed, the fields corresponding to the number of packets analyzed for this flow, to the sum of the sizes of the analyzed packets, and to the reference time of passage of the last analyzed packet, respectively the 'Packets', 'Bytes' and 'Last' fields, are updated.
  • the measurement unit of the router initiates an analysis for this stream, storing, among other things, a time reference for the passage of the first stream packet in the field ' First '.
  • the router measurement unit ends the analysis of a flow upon detection of the end of the flow.
  • a measurement unit is generally adapted to export the stored data either when the end of the flow is detected, or even before the end of the flow being analyzed, when a certain time has passed since the initiation of the flow analysis.
  • the stored data relating to the analysis of a flow are then encoded to be exported to the collection unit 18 in the form of flow description tickets.
  • flow description tickets relating to several studied flows can be grouped into a flow description block, as illustrated below.
  • the header of a description ticket for flux also preferably indicates a time reference of the router. Fields marked 'SysUptime' and 'UnixSecs' allow you to deduce when the flow description ticket was created. A field marked 'FlowSequence' allows the detection of loss of flow description tickets. Table 1 below describes the format of the header of the exported flow description tickets, according to an embodiment of the invention.
  • the 'Reserved' field can be used to describe information such as the transmitter (engine type 'and id') and a sampling method (samplingjnterval).
  • Each flow is preferably described in a flow description ticket as detailed in table 2 below, comprising in particular information relating to administrative domains, or AS for “Autonomous System” and relating to the Type of Service, or Tos, equivalent to a Quality of Service, or QoS.
  • Each flow can also be described by a flow description ticket comprising only part of the information listed above.
  • the flow description blocks grouping description tickets of flows are generally sent by the measurement units to a collection unit in the form of a UDP datagram.
  • a UDP datagram of 1464 bytes, corresponding to an Ethernet frame of 1500 bytes, can contain up to 30 flow description tickets.
  • An IPFIX-type service implemented in the form of software, does not generally make it possible to analyze all the packets passing through a network device.
  • the measurement unit therefore reduces the number of packets to be analyzed by selecting certain packets in the packet flow studied.
  • the invention covers all types of packet selection in a stream. In one embodiment of the invention, the selection of packets to be analyzed is carried out by sampling the flow studied.
  • the measurement units export the flow information, as detailed in table 2, to the collection unit 18.
  • test packets are injected into the network.
  • the terminal 11 transmits a stream of test packets intended for the terminal 12 through the network 10.
  • the stream of test packets therefore transits via at least some of the devices of the network 10.
  • all the test packets or only part of the test packets of the flow are analyzed.
  • the measurement units have the capacity to detect certain packets among the different packet streams passing through the network equipment with which they are associated, such as in particular different connection management packets.
  • the measurement units have the capacity to detect session status control packets, such as a session opening or end packet, or even a session pause packet. More precisely, in an IP type network, such measurement units are suitable for detecting TCP connection management packets. Generally, the measurement units implementing an IPFIX type service have such a capacity. When a measurement unit detects a management packet for a TCP connection, it exports this information in the TcpFlags' field of a flow description ticket according to IPFIX, as shown in table 2 with the presence of the TcpFlags' field. The following sections describe the basics of TCP connections. A format of a packet header according to a TCP type protocol is detailed in FIG. 4.
  • the server then returns an acknowledgment message to the client.
  • the TCP connection is established.
  • the client sends a connection close message to the server.
  • the 'END' field of the TCP header of such a message is equal to 1 and therefore such a message is noted END.
  • the server responds to this message by sending an acknowledgment message.
  • the client sends a connection closing message.
  • the 'RST' field of the TCP header of such a message is equal to 1 and therefore such a message is noted RST thereafter.
  • the collection unit 18 This characteristic of the test flow allows the collection unit 18 to carry out a correlation in a simple manner between the different information exported by the terminals and the measurement units, respectively in descriptions of packet flows and in flow descriptions.
  • the flow descriptions exported by the measurement units include fields relating to the various TCP connection management messages, noted TcpFlags'. Consequently, the collection unit receiving on the one hand a description of test packet flow from the sending terminal 11, then a description of test packet flow from the destination terminal 12, and on the other hand receiving a description of test flow from measurement units can correlate this information to easily obtain packet-by-packet information such as packet loss measurements on segments of the full path, i.e. between a terminal and network equipment or between two network equipment. Such measures are called packet loss vectors.
  • a description of such a flow makes it possible to detect whether none, one or both packets of the flow have passed through and have been analyzed by a measurement unit associated with a given network equipment. If no packet of the flow has been analyzed, the TcpFlags' field of the flow description ticket sent by the measurement unit associated with this equipment does not contain the SYN indications or RST. On the other hand, if the connection opening message packet and / or the connection closing message packet is analyzed by a measurement unit, the TcpFlags' field contains the indication SYN and / or RST.
  • a description of the test flow makes it possible to deduce a description of the flow of test packets and from this to deduce a vector of packet loss over a segment of the complete path.
  • the collection unit can deduce information from the values contained in the TcpFlags' field. So if the TcpFLags' field
  • the collection unit can deduce therefrom that the SYN packet has not been lost.
  • the flow descriptions exported by the measurement units preferably further include fields relating to the passage time references of the first packet and of the last packet of a flow, respectively denoted 'First' and 'Last'.
  • the test flow comprising only two test packets, the measurement unit indicates via the two fields 'First' and 'Last' of the flow description tickets, a time reference of each of the packets of a test flow, in case the two packets are analyzed.
  • the collection unit is thus able to simply carry out a correlation, packet by packet, between the descriptions of packet flows received from the terminals and the descriptions of flows received from the measurement units.
  • the collection unit 18 is able to provide the following instantaneous information: information relating to the path of the packets of the stream in the network; such as for example a list of one or more pieces of equipment through which the analyzed packets pass; information relating to the management of the equipment of the flow path in the network, such as for example a list of management addresses of one or more equipment through which the analyzed packets pass; information relating to the processing of the flow in the equipment of the path, such as for example a list of service quality levels applied by one or more equipment to the analyzed packets; or a list of administrative areas crossed by the flow; - network performance information relating to a packet loss on a segment between one of the terminals and a device or between two devices and / or to a packet transmission delay relating to a segment between one of the terminals and a device or between two equipment.
  • the unity of. measure can provide by iteration and by correlation of the information obtained at each iteration, relative to a segment between one of the terminals and one device or between two devices, statistics on performance measures such as those defined in the IETF, for "Internet Engineering Task Force ", or at PITU," for "International Telecommunication Union", such as: loss of packets; a packet transmission delay; and a variation in transmission delay.
  • a reiteration of the measurement process is also very useful in the case where the analysis is carried out on selected packets of the test flow, by sampling for example.
  • the collection unit is able to supply, by correlation of the data obtained at each iteration, in a more precise and exhaustive manner the following information: information relating to the path of the packets of the flow in the network ; such as for example a list of one or more pieces of equipment through which the analyzed packets pass; - information relating to the management of the equipment of the path of the flow in the network, such as for example a list of management addresses of one or more devices through which the analyzed packets pass; information relating to the processing of the flow in the equipment of the path, such as for example a list of service quality levels applied by one or more equipment to the analyzed packets; or a list of administrative areas crossed by the flow; network performance information relating to a packet loss on a segment between one of the terminals and a device or between two devices and / or a packet transmission delay relating to a segment between one of the terminals and a device or between two equipment.
  • FIG. 2 illustrates a network measurement method according to an embodiment of the invention.
  • the flow of test packets sent by the terminal 11 to the terminal 12 passes through the equipment 13 and 15, each being provided with a flow measurement unit comprising an IPFIX type flow description export function.
  • the measurement units sample, manage and store the flow descriptions in a table of flow characteristics.
  • a network comprises an integer number N of devices.
  • the flow descriptions are sent to the collection unit 18 from one of the IP addresses of the equipment Ei, denoted Ei_SrcAddrMgt.
  • the packets of the IP flow, transmitted by the terminal 11 to the terminal 12, are therefore observed during their passage through the equipment Ei.
  • step 21 the terminal 11 requests the opening of a TCP connection with the terminal 12. It sends a TCP message, whose SYN field has the value 1, to the terminal 12.
  • the terminal 11 stores a reference time, noted T11_SYN_time, relating to the time of transmission of the packet.
  • the characteristics of the test flow are: - T11_SrcAddr; - T11_SrcPort; - T12_DstAddr; - T12_DstPort. - TCP protocol.
  • the packet sent during the previous step is presented to the analysis process of each network device through which it passes, if it is selected.
  • the analysis process to which the first packet is presented detects the start of a new TCP connection, by checking the value of the “SYN” field of the TCP header of the packet. It therefore creates an entry in the flow characteristics table for this connection. Then, in one embodiment of the invention, the process assigns a value to the different fields of the table entry.
  • the terminal 12 receives a request to open the TCP connection. It stores a time reference of the arrival of the packet in the T12_SYN_time 'field. Then responds by sending a package including a
  • This description preferably contains the following information: - T11_SrcAddr; - T11_SrcPort; - T12_DstAddr; - T12_DstPort; - protocol; - T11_SYN_time; - T11_RST_time; - Tcp_flags; - T11_AS; - T11_Tos.
  • the description sent to the collection unit is detailed in the following table.
  • step 27 ' the analysis process to which the last packet is presented detects the end of a TCP connection, by checking the value of the' RST 'field of the TCP header of the packet. If no entry exists for this flow, the analysis process creates a new entry in the flow characteristics table. Otherwise, an entry already exists for this stream and the process increases the value of the 'Byte' field of the table entry by the number of bytes in the packet. It increases the value 'Packets' by the value 1 from the table entrance. Then, whether the entry is new or not, it assigns a time reference of the time of arrival of the packet to the 'Last' field of the table entry. Finally, a flow description is generated and sent to the collection unit. The entry from the corresponding table is then preferably freed.
  • the table below details an entry from the table of flow characteristics of the network equipment Ei for a given test flow.
  • the source AS is denoted A and TAS destination is noted B.
  • step 28 the units of measure prepare a description of flux. These flow descriptions can also be grouped in blocks of flow descriptions before being sent to the collection unit.
  • the flow descriptions are sent to the collection unit from the address Ei_SrcAddrMgmt.
  • the destination address for this package is Ei_DstAddrMgmt.
  • the present invention also covers the configuration in which the measurement units store the flow descriptions and the collection unit downloads them when it wishes.
  • the terminal 12 receives a connection termination message packet from the terminal 11. On receipt of this packet, it stores a reception time reference in T12_RST__time.
  • step (30) the terminal 12 sends to the collection unit the description of test packet flows.
  • This description contains the following information: - T11_SrcAddr; - T11_SrcPort; - T12_DstAddr; - T12_DstPort; - protocol; - T12_SYN_time; - T12_RST_time; - Tcp_flags; - T12_AS; - T12_Tos.
  • the collection unit 18 groups together the flow descriptions received from the measurement units and the packet flow descriptions received from the terminals. The table below details the information thus gathered.
  • step 32 in one embodiment of the invention, depending on the configuration of the collection unit, the latter can provide: information relating to the path of the packets of the flow in the network; - information relating to the management of the equipment of the flow path in the network; - information relating to the processing of the flow in the equipment of the path; network performance information relating to a loss of packets on a segment between one of the terminals and a device or between two devices and / or to a delay in transmission of packets on a segment between one of the terminals and a device or between two equipment and / or a variation in packet transmission delay. It can also calculate packet transmission delays and packet losses along the full path of the stream, as illustrated in the examples described in the following sections.
  • the collection unit supplies “End-to-end” NextHop vectors by grouping NextHop information from the SYN and RST packets, starting from step (31).
  • the collection unit provides management interface vectors, by grouping the management interface information of the SYN and RST packets of the test flow, from step 31.
  • the collection unit supplies AS vectors, by grouping the AS information of the SYN and RST packets analyzed and identified by the collection unit, from step 31
  • the AS of the source of the flow and the AS of the destination of the flow are respectively described in the fields exported by the terminals, Src_AS and Dst_AS.
  • a measurement unit exports, for a given Ei device, the previous AS in the path and the next AS in the path, that is to say the AS of the NextHop of the flow.
  • the case described below proves to be very useful in an IP network for a flow path passing through several different ASes. Knowledge of the list of ASs crossed by a flow makes it possible to establish an inter-domain diagnosis.
  • the table below groups the information from the ASes of the SYN and RST packets to produce AS vectors relating to segments of the flow path.
  • the collection unit provides Tos (or QoS) vectors by grouping together the information from the SYN and RST packets, as detailed in the table below.
  • the Tos field is one of the rare fields that network equipment is authorized to modify. This field determines the quality level of packet processing in the queues of network equipment. This is important information, particularly in inter-domain for the establishment of systems for marking the quality of services.
  • the final vector is therefore ⁇ T11_Tos, ..., Ei_Tos, Ei + 1_Tos, ..., T12_ToS ⁇ .
  • the collection unit can also calculate an end-to-end packet transmission delay vector according to one of the following equations: T12_SYN_time - T11_SYN_time; T12_RST_time - T11_RST_time.
  • the vectors of loss and delay are complementary. A packet observed by T12 makes it possible to calculate a transmission delay as illustrated in the table below.
  • an unobserved pack makes it possible to calculate a loss.
  • a loss of a SYN packet between the equipment Ei + 1 and the terminal 12 is detected as illustrated by the table below.
  • the terminal 11 sends a TCP connection opening message to the terminal 12.
  • the corresponding packet is observed by the network equipment Ei, Ei + 1 ...
  • This message is clearly not received by the terminal 12.
  • the terminal 11 does not receive a corresponding acknowledgment message.
  • the SYN message is retransmitted by the terminal 11.
  • the network equipment considers that a new connection, therefore a new flow, is to be processed.
  • a new entry in the flow characteristics table is then created.
  • a loss of an RST packet between the network equipment Ei and Ei + 1 is detected. This loss is confirmed by the fact that the RST packet is not received by T12.
  • FIG. 3 illustrates a method according to an embodiment of the invention in a network architecture based on a collection unit comprising a first and a second module.
  • the method then comprises the following steps: - step 302: Sending to the terminal 11 and to the second module 301 of a message requesting the copying of the description of the test flow description between the terminals 11 and 12, corresponding to a start of measurement , by the first module 300; step 21: sending the first packet corresponding to a TCP connection request from the terminal 11 to the terminal 12; - step 22, 22 ': Presentation of the first packet to the process of analyzing the flow of the measurement units of the Ei equipment; - step 23, 23 ': Creation of a new entry in the table of flow characteristics managed by the flow measurement units of the equipment Ei, at this stage a time reference for the passage of the first packet analyzed in the 'First' field is stored; step 24: reception of the first connection request packet by the terminal 12 and transmission of an acknowledgment SYN-ACK message by the terminal 12 to the terminal 11; - step 25: Receipt of the SYN-ACK acknowledgment message by the terminal 11 and sends an RST message to close the TCP connection to
  • step 26 Sending the description of packet flows by the terminal 11 to the first module 300; - step 27, 27 ': End of flow detection on reception of the RST packet and recording of a time reference for the passage of this last packet in the' Last 'field by the measurement units; - step 28, 28 ': Export of the flow descriptions by the measurement units of the equipment Ei to the second module 301; - step 29: Reception of the connection closure packet by the terminal 12; step 30: Sending the description of packet flows by the terminal 12 to the first module 300; step 303: Transmission over the flow of flow descriptions between the terminals 11 and 12 by the second module 301 to the first module 300; step 304: Grouping and correlation of the data relating to this flow by the first module 300; step 305: Production of the information vectors relating to equipment of the flow path or to segments of the path taken by the packets of this flow or also relating to the complete path by the first module 300.
  • the module 300 of the collection unit comprises an input filtering making it possible to filter only the information relating to the flows studied.
  • a flow description ticket also includes a TTL 'field, for Time To Live. Such information is conventionally included in a field of a flow packet. By exporting this information, the collection unit is thus able to easily schedule the Ei equipment along the flow path.
  • the present invention proves to be very advantageous in all fields of metrology of packet transmission networks, in particular for the dimensioning of the network, as well as for the commissioning and maintenance of the network and for the quality control of service provided.
  • an embodiment of the invention makes it possible to very quickly locate the segment or segments of the complete path which are the cause of the problems, on the basis very precise and reliable relative measurements.
  • the measurements provided are available and can be used very quickly.
  • an embodiment of the invention is very simple to implement in existing networks. It should also be noted that it is easy to deduce from the present description an embodiment of the present invention in which a terminal transmits the packet stream intended for several terminals. Thus, the measurement method according to an embodiment of the invention can be easily applied to a multiple destination transmission, or “multicast” in English.
  • the function of the collection unit as stated above can advantageously be fulfilled by a plurality of entities arranged in a hierarchical architecture.
  • a collection unit comprises a plurality of collection entities and a central entity. The terminal and the measurement unit are then connected to at least one of the collection entities.
  • a terminal can send packet flow descriptions to one of the collection entities and one measurement unit can send flow descriptions to another collection entity. Then, each of these collection entities can then transmit the descriptions received to the central entity, which identifies each analyzed packet of the flow as a function of the flow description to correlate, packet by packet, the flow description and the flow description packets thus received.

Abstract

Un flux de paquets de données émis par un terminal (11) transite via un équipement de réseau (13) auquel est associée une unité de mesure de flux. Le terminal (11) et l'unité de mesure sont reliés à une unité de collecte (18). Le terminal génère un flux comprenant un premier et un second paquets à destination du second terminal. L'unité de mesure analyse un des paquets du flux. Puis, l'unité de collecte reçoit du terminal une description de flux de paquets comprenant une information indiquant le nombre de paquets émis, respectivement le nombre de paquets reçus, et de l'unité de mesure une description du flux comprenant le nombre de paquets analysés. L'unité de collecte (18) corrèle, paquet par paquet, les descriptions reçues.

Description

Λ
MESURE DE PERFORMANCE DANS UN RESEAU DE TRANSMISSION DE PAQUETS
La présente invention est relative au domaine des réseaux de télécommunication et plus précisément au domaine de la métrologie des réseaux de télécommunications de transmission de paquets. La métrologie, au sens littéral « science des mesures », se développe dans différents domaines des réseaux tels que la caracterisation et la modélisation de trafic, l'analyse de trafic, ou encore l'optimisation de la qualité de service et des performances. La métrologie des réseaux est également utilisée pour améliorer la supervision d'un réseau. Elle a pour objectif notamment de fournir une aide pour le dimensionnement d'un réseau et pour le diagnostic de problèmes détectés dans un réseau. La complexité grandissante des réseaux et notamment celle du réseau Internet entraîne une méconnaissance du trafic et des conditions d'utilisation. Il devient de plus en plus difficile d'avoir une réelle maîtrise du réseau et de son comportement. Généralement, le trafic d'un réseau est composé de plusieurs flux de paquets. Un flux de paquets est défini comme étant un échange de données entre deux terminaux d'un réseau dont les paquets ont des caractéristiques communes, notamment des caractéristiques communes d'origine, de destination et de service. De manière générale, la métrologie a pour objectif de déterminer des mesures à réaliser sur le trafic du réseau étudié afin d'avoir une meilleure connaissance de ce trafic. On connaît deux grands types de mesures. Un premier type est composé de mesures réalisées sur un flux de paquets de test. Pour effectuer ces mesures dites "actives", on émet, à travers le réseau étudié, depuis un premier terminal émetteur vers un second terminal récepteur un flux de paquets de test. Généralement un paquet de test a un format spécifique contenant un premier champ indiquant une référence temporelle d'émission du paquet et un second champ indiquant le numéro de séquence du paquet dans le flux des paquets de test émis. Par conséquent, le terminal récepteur détermine un délai de transmission d'un paquet de test depuis le terminal émetteur en fonction du premier champ du paquet. Le terminal récepteur peut également détecter des pertes de paquets en fonction du second champ d'un paquet de test. Plus généralement, un paquet de test est un paquet dont on connaît une référence temporelle d'émission et que l'on sait distinguer des autres paquets en réception afin de lui associer une référence temporelle d'arrivée ou bien de déterminer si il est perdu. On peut ainsi obtenir des caractéristiques de performance d'un flux « de bout en bout », c'est-à-dire sur le chemin complet du flux des paquets de test, depuis l'émetteur jusqu'au récepteur, et notamment des mesures de délai de transmission entre les deux terminaux, sur la base de références temporelles connues d'émission et de réception des paquets. Ce premier type de mesure permet donc d'obtenir des mesures de performance sur un chemin complet du flux de paquets de test, c'est-à-dire entre le terminal émetteur du flux et le terminal récepteur du flux. Les mesures ainsi obtenues sont relatives aux paquets de test d'un flux. Elles sont de ce fait qualitativement précises. Un inconvénient de ce type de mesures est qu'il ne fournit que des informations relatives aux extrémités du flux de paquets de test. Il est de ce fait impossible d'obtenir des informations sur un segment du chemin complet entre deux équipements de réseau ou encore entre un équipement de réseau et un des terminaux. Les informations ainsi obtenues sont donc géographiquement imprécises. On connaît un deuxième type de mesures réalisées au niveau d'un équipement de réseau par une analyse des flux qui transitent par lui. Ces mesures dites "passives" peuvent être réalisées soit par des unités de mesure embarquées dans les équipements de réseau, soit par des unités de mesure externes aux équipements de réseau (ou encore sondes passives) dédiées aux mesures passives. Ces dernières disposent en général de moins d'information que les unités de mesure embarquées. Ces unités de mesure sont en écoute du trafic circulant sur les liaisons entre les équipements de réseau. Ce type de mesure passive, largement utilisé dans les réseaux existants, permet d'obtenir des informations de volumétrie par flux et par équipement de réseaux. Un inconvénient de ce type de mesure est qu'il fournit des informations relatives à un équipement de réseau qui sont très difficiles à corréler avec d'autres informations relatives à un autre équipement de réseau. Par conséquent, même s'il est toutefois possible d'obtenir par corrélation des informations géométriques relativement précises sur un segment donné, une telle corrélation reste complexe à mettre en œuvre, notamment dans le cas où on échantillonne les flux pour les analyser. Un autre inconvénient de ce type de mesures est qu'il ne fournit que des informations voluméfriques relatives au flux par équipements de réseaux, notamment le nombre de paquets analysés ainsi que la somme des tailles des paquets analysés pour un flux donné. Par conséquent, les informations obtenues par ce type de mesures peuvent s'avérer être qualitativement insuffisantes et même peu fiables, notamment dans le cas où on échantillonne les flux pour les analyser. Ainsi, il est intéressant d'obtenir des informations qualitativement précises, c'est-à-dire relatives aux paquets d'un flux, et géographiquement précises, c'est-à-dire relatives à des segments du chemin complet du flux dans les réseaux existants. On note que les termes « équipement de réseau » font référence à un équipement de réseau actif, c'est-à-dire qui remplit une fonction de traitement actif dans le réseau, comme par exemple les commutateurs ou encore les routeurs. Une fonction de traitement actif dans le réseau peut également se définir par opposition à une fonction de traitement passif remplie notamment par une unité de mesure. La présente invention vise à proposer une solution tendant à satisfaire ces besoins. Un premier aspect de l'invention propose un procédé de mesure dans un réseau de transmission de paquets de données, dans lequel un flux de paquets de données émis par un premier terminal transite via au moins un équipement de réseau auquel est associée une unité de mesure de flux, dans lequel ledit premier terminal et ladite unité de mesure sont reliés à une unité de collecte, ledit procédé comprenant les étapes suivantes : le premier terminal génère un flux de paquets, comprenant un premier et un second paquets de contrôle d'état de session; l'unité de mesure analyse ledit premier et/ou second paquet dudit flux, transitant par l'équipement de réseau ; le premier terminal envoie une description de flux de paquets émis comprenant au moins le nombre de paquets émis à l'unité de collecte ; l'unité de mesure de flux envoie une description du flux comprenant au moins une information indiquant le nombre de paquets analysés à l'unité de collecte ; et l'unité de collecte identifie chaque paquet analysé du flux en fonction de la description de flux pour corréler, paquet par paquet, ladite description de flux et ladite description de flux de paquets. Un deuxième aspect de l'invention propose un système de mesure comprenant des moyens agencés pour mettre en œuvre le procédé ci-dessus. Un troisième aspect de l'invention propose une unité de collecte comprenant des moyens agencés pour mettre en œuvre le procédé ci-dessus. Grâce à ces dispositions, on peut obtenir des informations précises géographiquement et qualitativement du trafic sur le réseau de transmission étudié. D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - la figure 1 est un schéma d'une architecture du réseau selon un mode de réalisation de l'invention ; - la figure 2 illustre un procédé de mesure de réseau selon un mode de réalisation de l'invention ; - la figure 3 illustre un procédé selon un mode de réalisation de l'invention dans une architecture du réseau basée sur une unité de collecte comprenant un premier et un second module ; - la figure 4 illustre un format d'un en-tête de paquet TCP. L'invention peut être exploitée dans tous les domaines de la métrologie appliquée aux réseaux de transmission de paquets. L'invention propose de coupler des mesures actives et des mesures passives afin de tirer avantage de chacune d'elles. Ainsi, dans un mode de réalisation de l'invention, deux terminaux (ou sondes actives) échangent un paquet de test qui est analysé en plusieurs points du réseau, notamment sur la base des références temporelles de passage de ce paquet. Le contexte de l'invention est celui de tout type de réseau de transmission de paquets de taille fixe et de taille variable. Afin d'illustrer la description ci-après, le réseau IP, pour « Internet Protocol », est pris en exemple, sans limiter la portée de l'invention. L'invention peut notamment être mise en œuvre sur un protocole IP version 4 ou version 6. L'invention s'applique aux méthodes d'analyse comprenant une sélection de paquets des flux analysés, comme par exemple un échantillonnage de flux, ou encore aux méthodes d'analyse sans sélection de paquets des flux analysés. On note que, dans un mode de réalisation de l'invention, une unité de mesure génère des descriptions de flux comprenant des informations relatives au flux, alors qu'un terminal génère des description de flux de paquets comprenant des informations relatives à des paquets du flux. La figure 1 représente une architecture de réseau comprenant un système de mesure selon un mode de réalisation de l'invention. Un terminal 11 et un terminal 12 sont connectés au réseau IP 10. Les terminaux 11 et 12 sont adaptés à la génération des flux de paquets de test. Le réseau IP 10 comprend des équipements respectivement référencés
13, 14, 15, 16 et 17. Parmi ces équipements, les équipements 13, 15 et 16 sont chacun pourvus d'une unité de mesure de flux embarquée. Les unités de mesure comprennent une fonction d'exportation de mesures. L'invention couvre également une configuration dans laquelle l'unité de mesure de flux est une entité extérieure et en écoute du trafic transitant sur un lien de transmission entre les équipements de réseau. ou un terminal et un équipement. Les terminaux 11 et 12 ainsi que les équipements comprenant des unités de mesure de flux 13, 15 et 16 sont reliés à une unité de collecte 18.
Cette unité de collecte est destinée à recevoir les différentes informations exportées par les unités de mesures et les terminaux 11 et 12 afin de les regrouper et de les corréler pour fournir des informations précises, relatives aux paquets de test du flux et correspondantes à des segments déterminés du chemin complet du flux, notamment des informations de performance relatives à la perte de paquets ou au délai de transmission de paquets. Les terminaux 11 et 12 peuvent être des terminaux fixes. Ils peuvent également être des terminaux mobiles. Dans un mode préféré de réalisation de l'invention, les unités de mesure de flux embarquées dans les équipements 13, 15, 16 mettent en œuvre des fonctions d'analyse de flux du genre de celles en cours de normalisation nommées 'IPFIX' dont une implémentation est distribuée par la société Cisco Systems, Inc. sous l'appellation « Netflow ». Un service de type « IPFIX » est un service global d'analyse de flux transitant par des équipements de réseaux de transmission de paquets, notamment des routeurs et des commutateurs de type IP, ATM, Ethernet ou encore MPLS (pour Multiple Protocole Lable Switch). Un tel service fournit une analyse des flux entrant dans un équipement. Il est également adapté pour accumuler des mesures statistiques relatives à un flux donné ainsi que pour exporter de manière asynchrone ces mesures vers une unité de collecte 18. L'exportation des mesures vers l'unité de collecte est de préférence réalisée par encodage des données afin de réduire la bande passante nécessaire. Une telle exportation des mesures peut être réalisée au fil de l'eau, sur expiration d'un temporisateur, ou sur détection d'une fin de flux. Une unité de mesure peut aussi stocker ces mesures de manière à permettre à l'unité de collecte 18 de les télécharger. L'invention couvre toute autre fonction d'analyse d'une unité de mesure fournissant des informations de flux et toute autre méthode d'exportation de ces informations de flux. Dans les sections suivantes, par souci de clarté et à titre d'exemple, les équipements de réseau pourvus d'une unité de mesure de flux sont des routeurs. L'invention couvre également un système de mesure de flux dans lequel les équipements de réseau pourvus d'une unité de mesure de flux sont d'autres équipements de réseau, comme par exemple des commutateurs. Généralement, un flux de paquets de test, émis par le terminal 11 à destination du terminal 12, est identifié par les informations suivantes : l'adresse IP, notée T11_SrcAddr, et le port logique, noté T11_SrcPort, du terminal émetteur 11 ; l'adresse IP, notée T12_DstAddr, et le port logique, noté T12_DstPort, du terminal récepteur 12 ; le protocole utilisé, noté Proto_test, par exemple TCP pour « Transmission Control Protocol », UDP pour « User Datagram Protocol », ou encore ICMP pour « Internet Control Message Protocol ». Un équipement de réseau pourvu d'une unité de mesure de flux est en mesure de fournir les descriptions de flux comprenant, de préférence: un champ pour le numéro d'interface d'entrée et de sortie, respectivement noté 'Input' et 'Output' ; un champ pour le nombre de paquets analysés et comptabilisés pour un flux, noté 'Packets' ; un champ pour le nombre d'octets de la couche protocolaire IP correspondant aux paquets analysés du flux, noté 'Octets' ; un champ pour une référence temporelle de passage du premier paquet analysé dans le flux et un champ pour une référence temporelle de passage du dernier paquet analysé dans ce flux, respectivement noté 'First' et 'Last' ; un champ pour l'adresse IP de l'interface d'entrée du prochain routeur, notée 'NextHop'. Lorsqu'un tel équipement est un routeur, une description de flux comprend en outre de préférence, un champ pour les numéros de domaines administratifs, ou AS pour « Autonomous System », traversés, respectivement notés 'SrcAS' et 'DstAS'. Une unité de mesure d'un routeur stocke des données relatives aux flux qui traversent ce routeur. Sur réception d'un paquet, l'unité de mesure détermine si le paquet appartient à un flux en cours d'analyse. S'il appartient à un flux en cours d'analyse, les champs correspondant au nombre de paquets analysés pour ce flux, à la somme des tailles des paquets analysés, et à la référence temporelle de passage du dernier paquet analysé, respectivement les champs 'Packets', 'Octets' et 'Last', sont mis à jour. Si le paquet reçu n'appartient pas un flux en cours d'analyse, l'unité de mesure du routeur initie une analyse pour ce flux, en stockant, entre autre, une référence temporelle de passage du premier paquet de flux dans le champ 'First'. L'unité de mesure du routeur termine l'analyse d'un flux sur détection de la fin du flux. Une unité de mesure est en général adaptée pour exporter les données stockées soit lorsque la fin du flux est détectée, ou encore avant la fin du flux en cours d'analyse, lorsqu'un certain temps s'est écoulé depuis l'initiation de l'analyse du flux. Les données stockées relatives à l'analyse d'un flux sont alors encodées pour être exportées vers l'unité de collecte 18 sous la forme de tickets de description de flux. Plusieurs tickets de description de flux relatifs à plusieurs flux étudiés peuvent être groupés en un bloc de description de flux, comme cela est illustré ci-après. Outre les données techniques nécessaires au décodage d'un ticket de description par l'unité de collecte 18, notamment un champ noté 'Version' identifiant une version logicielle du service de type IPFIX, l'en-tête d'un ticket de description de flux indique également, de préférence, une référence temporelle du routeur. Des champs notés 'SysUptime' et 'UnixSecs' permettent de déduire à quel moment a été créé le ticket de description de flux. Un champ noté 'FlowSequence' permet la détection de pertes de tickets de description de flux. La table 1 ci-dessous décrit le format de l'en-tête des tickets de description de flux exportés, selon un mode de réalisation de l'invention.
Dans cette table le champ 'Reserved' peut être utilisé pour décrire des informations comme l'émetteur (engine type' et id') et une méthode d'échantillonnage (samplingjnterval). Chaque flux est de préférence décrit dans un ticket de description de flux tel que détaillé dans la table 2 ci-après, comprenant notamment des informations relatives aux domaines administratifs, ou AS pour « Autonomous System » et relatives au Type de Service, ou Tos, équivalent à une Qualité de Service, ou QoS.
Table 2
Chaque flux peut également être décrit par un ticket de description de flux ne comprenant qu'une partie seulement des informations listées ci-dessus. Les blocs de description de flux groupant des tickets de description de flux sont en général envoyés par les unités de mesure à une unité de collecte sous la forme d'un datagramme UDP. Un datagramme UDP de 1464 octets, correspondant à une trame Ethernet de 1500 octets, peut contenir jusqu'à 30 tickets de description de flux. Un service de type IPFIX, implémenté sous la forme d'un logiciel, ne permet pas, en général, d'analyser tous les paquets transitant par un équipement de réseau. L'unité de mesure réduit donc le nombre de paquets à analyser en sélectionnant certains paquets dans le flux de paquets étudié. L'invention couvre tout type de sélection de paquets dans un flux. Dans un mode de réalisation de l'invention, la sélection de paquets à analyser est réalisée par échantillonnage du flux étudié. Ensuite, les unités de mesures exportent les informations de flux, comme détaillées dans la table 2, vers l'unité de collecte 18. Comme cela a été précédemment dit, des paquets de test sont injectés dans le réseau. En effet, le terminal 11 émet un flux de paquets de test à destination du terminal 12 à travers le réseau 10. Le flux de paquets de test transite de ce fait via au moins certains des équipements du réseau 10. Lors du passage des paquets de test dans les équipements de réseaux pourvus d'une unité de mesure, tous les paquets de test ou seulement une partie des paquets de test du flux sont analysés. Dans un mode de réalisation de l'invention, les unités de mesure ont la capacité de détecter certains paquets parmi les différents flux de paquets transitant par les équipements de réseau auxquels elles sont associées, comme notamment différents paquets de gestion de connexions. De manière générale, les unités de mesure ont la capacité de détecter des paquets de contrôle d'état de session, comme un paquet d'ouverture de session ou de fin de session, ou encore comme un paquet de pause d'une session. Plus précisément, dans un réseau de type IP, de telles unités de mesure sont adaptées pour détecter des paquets de gestion des connexions TCP. Généralement, les unités de mesure mettant en œuvre un service de type IPFIX ont une telle capacité. Lorsqu'une unité de mesure détecte un paquet de gestion d'une connexion TCP, elle exporte cette information dans le champ TcpFlags' d'un ticket de description de flux selon IPFIX, comme indiqué dans la table 2 avec la présence du champ TcpFlags'. Les sections suivantes décrivent les principes de base des connexions TCP. Un format d'un en-tête de paquet selon un protocole de type TCP est détaillé dans la figure 4. Le champ drapeau 'RST est égal à 1 quand la connexion est réinitialisée. Le champ drapeau 'SYN' est égal à 1 quand on initialise une connexion. Le champ drapeau 'FIN' est égal à 1 quand la connexion s'interrompt. Pour établir une connexion TCP, le client et le serveur échangent des données et des accusés de réception. L'établissement classique d'une telle connexion est réalisé en trois étapes. Tout d'abord, le client envoie un message de demande de connexion au serveur. Le champ 'SYN' de l'en-tête TCP d'un tel message est égal à 1 et de ce fait un tel message est noté SYN par la suite.
Puis, le serveur renvoie un message d'accusé de réception au client. Le champ
'SYN' et le champ 'ACK' de l'en-tête TCP d'un tel message sont égaux à 1 et de ce fait un tel message est noté SYN-ACK par la suite. Enfin, le client répond à ce dernier message par un message d'accusé de réception. Le champ 'ACK' de l'en-tête TCP d'un tel message est égal à 1 et de ce fait un tel message est noté
ACK par la suite. A l'issue de cet échange de message, la connexion TCP est établie. Pour fermer une connexion TCP, le client envoie un message de fermeture de connexion au serveur. Le champ 'FIN' de l'en-tête TCP d'un tel message est égal à 1 et de ce fait un tel message est noté FIN. Le serveur répond à ce message par l'envoi d'un message d'accusé de réception. Il existe une procédure plus rapide de fermeture de connexion TCP dans laquelle seul un message est envoyé : le client envoie un message de fermeture de connexion. Le champ 'RST' de l'en-tête TCP d'un tel message est égal à 1 et de ce fait un tel message est noté RST par la suite. Généralement, une unité de mesure mettant en œuvre un service de type IPFIX traite un flux TCP de manière particulière en sorte qu'un paquet SYN détecté marque le début d'un flux et qu'un paquet RST, ou encore un paquet FIN, détecté marque la fin d'un flux. Un mode de réalisation de l'invention tire partie de ce traitement particulier. Avantageusement, les flux de tests générés par le terminal 11 à destination du terminal 12 transitant par les équipements de réseaux sont composés chacun de deux paquets de test. En effet, le terminal 11 ouvre une connexion TCP avec le terminal 12, par l'envoi d'un paquet comprenant un message d'ouverture de connexion.-Puis, sur réception du paquet d'accusé de réception correspondant, le terminal 11 ferme la connexion par l'envoi d'un paquet de fermeture de connexion. Par conséquent, un tel flux de test comprend un premier paquet de test SYN et un second paquet de test RST. Cette caractéristique du flux de test permet à l'unité de collecte 18 de réaliser une corrélation de manière simple entre les différentes informations exportées par les terminaux et les unités de mesure, respectivement dans des descriptions de flux de paquets et dans des descriptions de flux. Comme cela a été décrit ci-dessus, les descriptions de flux exportées par les unités de mesure comprennent des champs relatifs aux différents messages de gestion de connexion TCP, noté TcpFlags'. Par conséquent, l'unité de collecte recevant d'une part une description de flux de paquets de test depuis le terminal émetteur 11 , puis une description de flux de paquets de test depuis le terminal de destination 12, et recevant d'autre part une description de flux de test depuis les unités de mesure peut corréler ces informations pour obtenir de manière simple des informations paquet par paquet telles que des mesures de pertes de paquets sur des segments du chemin complet, c'est-à-dire entre un terminal et un équipement de réseau ou encore entre deux équipements de réseau. De telles mesures sont appelées vecteurs de perte de paquets. En effet, une description d'un tel flux permet de détecter si aucun, un ou les deux paquets du flux ont transité et ont été analysé par une unité de mesure associée à un équipement de réseau donné. Si aucun paquet du flux n'a été analysé, le champ TcpFlags' du ticket de description de flux envoyé par l'unité de mesure associée à cet équipement ne contient pas les indications SYN ou RST. En revanche, si le paquet du message d'ouverture de connexion et/ou le paquet du message de fermeture de connexion est analysé par une unité de mesure, le champ TcpFlags' contient l'indication SYN et/ou RST. Dans un tel mode de réalisation, une description du flux de test permet de déduire une description de flux de paquets de test et delà déduire un vecteur de perte de paquets sur un segment du chemin complet. On note que l'unité de collecte peut déduire des informations à partir des valeurs contenues dans le champ TcpFlags'. Ainsi, si le champ TcpFLags'
-contient l'indication RST, l'unité de collecte peut en déduire que le paquet SYN n'a pas été perdu. Par ailleurs, les descriptions de flux exportées par les unités de mesure comprennent en outre de préférence des champs relatifs aux références temporelles de passage du premier paquet et du dernier paquet d'un flux, respectivement notés 'First' et 'Last'. Le flux de test ne comprenant que deux paquets de test, l'unité de mesure indique via les deux champs 'First' et 'Last' des tickets de description de flux, une référence temporelle de chacun des paquets d'un flux de test, dans le cas où les deux paquets sont analysés. L'unité de collecte est ainsi en mesure de réaliser simplement une corrélation, paquet par paquet, entre les descriptions de flux de paquets reçues des terminaux et les descriptions de flux reçues des unités de mesure. Par conséquent, l'unité de collecte peut très facilement calculer des délais de transmission de paquet sur des segments du chemin complet du flux. De tels délais sont appelés vecteurs instantanés de délai de transmission des paquets. Plus généralement, l'unité de collecte 18 est en mesure de fournir des informations instantanées suivantes : - des informations relatives au chemin des paquets du flux dans le réseau ; comme par exemple une liste d'un ou plusieurs équipements par lesquels les paquets analysés transitent ; - des informations relatives à la gestion des équipements du chemin du flux dans le réseau, comme par exemple une liste d'adresses de gestion d'un ou plusieurs équipements par lesquels les paquets analysés transitent ; - des informations relatives au traitement du flux dans les équipements du chemin, comme par exemple une liste de niveaux de qualité de service appliqués par un ou plusieurs équipements aux paquets analysés ; ou encore une liste de domaines administratifs traversés par le flux ; - des informations de performance du réseau relatives à une perte de paquets sur un segment entre un des terminaux et un équipement ou entre deux équipements et/ou à un délai de transmission de paquets relatif à un segment entre un des terminaux et un équipement ou entre deux équipements. Dans certaines conditions, il peut s'avérer très utile de réitérer successivement les étapes d'émission de flux de paquets de test par le terminal 11 , d'analyse de flux dans les équipements de réseau et de réception de flux par le terminal 12. Dans de telles conditions l'unité de. mesure peut fournir par itération et par corrélation des informations obtenues à chaque itération, relativement à un segment entre un des terminaux et un équipement ou entre deux équipements, des statistiques sur des mesures de performance telles que celles définies à l'IETF, pour « Internet Engineering Task Force », ou à PITU, «pour « International Télécommunication Union », comme par exemple: une perte de paquets; un délai de transmission de paquets ; et une variation de délai de transmission. Une réitération du procédé de mesure est très utile également dans le cas où l'analyse est réalisée sur des paquets sélectionnés du flux de test, par échantillonnage par exemple. Ainsi, après réitération des étapes, l'unité de collecte est en mesure de fournir, par corrélation des données obtenues à chaque itération, de manière plus précise et exhaustive les informations suivantes : - des informations relatives au chemin des paquets du flux dans le réseau ; comme par exemple une liste d'un ou plusieurs équipements par lesquels les paquets analysés transitent ; - des informations relatives à la gestion des équipements du chemin du flux dans le réseau, comme par exemple une liste d'adresses de gestion d'un ou plusieurs équipements par lesquels les paquets analysés transitent ; - des informations relatives au traitement du flux dans les équipements du chemin, comme par exemple une liste de niveaux de qualité de service appliqués par un ou plusieurs équipements aux paquets analysés ; ou encore une liste de domaines administratifs traversés par le flux ; des informations de- performance du réseau relatives à une perte de paquets sur un segment entre un des terminaux et un équipement ou entre deux équipements et/ou à un délai de transmission de paquets relatif à un segment entre un des terminaux et un équipement ou entre deux équipements. On notera que la réitération des étapes s'avère être particulièrement avantageuse dans le cas où l'analyse est réalisée sur des paquets sélectionnés du flux de test, par échantillonnage par exemple. En effet, certains vecteurs instantanés peuvent dans ce cas fournir une information incomplète. En revanche, dans le cas où l'analyse est réalisée sur tous les paquets du flux de test, les données listées ci-dessus, peuvent être obtenues par corrélation sans réitération. La figure 2 illustre un procédé de mesure de réseau selon un mode de réalisation de l'invention. Le flux de paquets de test émis par le terminal 11 vers le terminal 12 traverse les équipements 13 et 15, chacun étant doté d'une unité de mesure de flux comprenant une fonction d'exportation de description de flux de type IPFIX. Dans un mode de réalisation de l'invention, les unités de mesures échantillonnent, gèrent et stockent les descriptions de flux dans une table des caractéristiques de flux. La structure des entrées de cette table est analogue à la structure décrite précédemment dans la table 2. Suivant le type de service du flux analysé, le niveau fonctionnel de l'analyse ou encore le type de l'équipement de réseau, cette table peut disposer de champs supplémentaires ou inversement, certains des champs déjà listés peuvent ne pas être renseignés. Dans un cas général, un réseau comprend un nombre entier N d'équipements. Les descriptions de flux sont envoyées à l'unité de collecte 18 à partir d'une des adresses IP de l'équipement Ei, notée Ei_SrcAddrMgt. Les paquets du flux IP, émis par le terminal 11 vers le terminal 12, sont donc observés lors de leur passage dans les équipements Ei. Dans un mode réalisation de l'invention, le procédé de mesure comprend les étapes suivantes : - étape 21 : Envoi du premier paquet correspondant à une demande de connexion TGP depuis le terminal 11 au terminal 12; - - étape 22, 22' : Présentation du premier paquet au processus d'analyse du flux des unités de mesure des équipements Ei ; - étape 23, 23' : Création d'une nouvelle entrée dans la table des caractéristiques de flux gérée par les unités de mesure de flux des équipements Ei, à cette étape on stocke une référence temporelle de passage du premier paquet analysé dans le champ 'First' ; - étape 24 : Réception du premier paquet de demande de connexion par le terminal 12 et émission d'un message d'acquittement SYN-ACK par le terminal 12 à destination du terminal 11 ; - étape 25 : Réception du message d'acquittement SYN-ACK par le terminal 11 et envoie d'un message RST de fermeture de connexion TCP à destination du terminal 12 ; - étape 26 : Envoi de la description de flux de paquets par le terminal
11 vers l'unité de collecte 18; - étape 27, 27' : Détection de fin de flux sur réception du paquet RST et enregistrement d'une référence temporelle de passage de ce dernier paquet dans le champ 'Last' par les unités de mesures ; - étape 28, 28' : Exportation des descriptions de flux par les unités de mesure des équipements Ei vers l'unité de collecte 18 ; - étape 29 : Réception du dernier paquet de fermeture de connexion par le terminal 12 ; - étape 30 : Envoi de la description de flux de paquets par le terminal
12 vers l'unité de collecte 18; - étape 31 : Regroupement et corrélation des données relatives à ce flux par l'unité de collecte 18; - étape 32 : Production des vecteurs d'informations relatifves à des équipements du chemin du flux ou à des segments du chemin empruntés par les paquets de ce flux ou encore relatifs au chemin complet par l'unité de collecte. Les sections suivantes détaillent chacune des étapes du procédé de mesure citées ci-dessus. Dans l'étape 21 , le terminal 11 demande l'ouverture d'une connexion TCP avec le terminal 12. Il émet un message TCP, dont le champ SYN a la valeur 1 , à destination du terminal 12. Le terminal 11 mémorise une référence temporelle, notée T11_SYN_time, relative à l'instant d'émission du paquet. Les caractéristiques du flux de test sont : - T11_SrcAddr ; - T11_SrcPort ; - T12_DstAddr ; - T12_DstPort. - Protocole TCP. Dans l'étape 22, 22', le paquet envoyé au cours de l'étape précédente est présenté au processus d'analyse de chaque équipement de réseau par lequel il transite, si il est sélectionné. Dans l'étape 23, 23', le processus d'analyse auquel est présenté le premier paquet détecte le début d'une nouvelle connexion TCP, en contrôlant la valeur du champ 'SYN' de l'en-tête TCP du paquet. Il crée donc une entrée dans la table de caractéristiques de flux pour cette connexion. Puis, dans un mode de réalisation de l'invention, le processus affecte une valeur aux différents champs de l'entrée de la table. Ainsi, il affecte une référence temporelle de l'instant d'arrivée du paquet au champ 'First' de l'entrée de la table. Puis il affecte le nombre d'octets du paquet IP au champ 'Octets' de l'entrée de la table. Il affecte la valeur 1 au champ 'Packets' de l'entrée de la table. Il affecte la valeur correspondant au drapeau SYN au champ TcpFlags' de l'entrée de la table. Il affecte la valeur de T11_SrcAddr au champ 'SrcAddr' de l'entrée de la table. Il affecte la valeur de T11_SrcPort au champ 'SrcPort' de l'entrée entrée de la table. Il affecte la valeur de T12_DstAddr au champ 'DstAddr' de l'entrée de la table. Il affecte la valeur de T12_DstPort au champ 'DstPoif de l'entrée de la table. Il affecte une valeur correspondant au protocole TCP au champ 'Proto' de l'entrée de la table. Dans l'étape 24, le terminal 12 reçoit une demande d'ouverture de connexion TCP. Il stocke une référence temporelle de l'arrivée du paquet dans le champ T12_SYN_time'. Puis répond par l'envoi d'un paquet comprenant un
—message- d'acceptation -de la connexion TCP. Un tel message est un paquet dont l'en-tête comprend le champ 'SYN' égal à 1 et le champ 'ACK' égal à 1. Dans l'étape 25, le terminal 11 reçoit le message d'acceptation de l'ouverture de la connexion TCP. Il répond à ce message par l'envoi d'un paquet comprenant un message de fermeture de connexion par réinitialisation. Il stocke une référence temporelle de l'émission de ce paquet dans le champ T11_RST_time'. Dans l'étape 26, le terminal 11 produit une description de flux de paquets de ce flux et l'envoie à l'unité de collecte 18. Cette description contient de préférence les informations suivantes : - T11_SrcAddr ; - T11_SrcPort ; - T12_DstAddr ; - T12_DstPort ; - protocole ; - T11_SYN_time ; - T11_RST_time ; - Tcp_flags ; - T11_AS; - T11_Tos. Dans le cas où le terminal 11 exporte les descriptions sous un format de type IPFIX, la description envoyée à l'unité de collecte est détaillée dans la table suivante.
Table 3 Dans l'étape 27, 27', le processus d'analyse auquel est présenté le dernier paquet détecte la fin d'une connexion TCP, en contrôlant la valeur du champ 'RST' de l'en-tête TCP du paquet. Si aucune entrée n'existe pour ce flux, le processus d'analyse crée une nouvelle entrée dans la table des caractéristiques de flux. Dans le cas contraire, une entrée existe déjà pour ce flux et le processus augmente la valeur du champ 'Octet' de l'entrée de table du nombre d'octets du paquet. Il augmente de la valeur 1 le champ 'Packets' de l'entrée de la table. Puis, que l'entrée soit nouvelle ou non, il affecte une référence temporelle de l'instant d'arrivée du paquet au champ 'Last' de l'entrée de la table. Enfin, une description de flux est générée et envoyée à l'unité de collecte. L"entrée de la table correspondante est ensuite de préférence libérée. La table ci-après détaille une entrée de la table des caractéristiques de flux de l'équipement de réseau Ei pour un flux de test donné. L'AS source est noté A et TAS destination est noté B.
Table 4 Dans l'étape 28, les unités de mesure préparent une description de flux. Ces descriptions de flux peuvent également être regroupées dans des blocs de descriptions de flux avant d'être envoyées à l'unité de collecte. Les descriptions de flux sont envoyées à l'unité de collecte depuis l'adresse Ei_SrcAddrMgmt. L'adresse destination de ce paquet est Ei_DstAddrMgmt. La présente invention couvre également la configuration dans laquelle les unités de mesure stockent les descriptions de flux et l'unité de collecte les télécharge lorsqu'elle le souhaite. Dans l'étape 29, le terminal 12 reçoit un paquet de message de fin de connexion du terminal 11. Sur réception de ce paquet, il stocke une référence temporelle de réception dans T12_RST__time. Dans l'étape (30), le terminal 12 envoie à l'unité de collecte la description de flux de paquets de test. Cette description contient les informations suivantes : - T11_SrcAddr ; - T11_SrcPort ; - T12_DstAddr ; - T12_DstPort ; - protocole ; - T12_SYN_time ; - T12_RST_time ; - Tcp_flags ; - T12_AS; - T12_Tos. Dans l'étape 31 , l'unité de collecte 18 regroupe les descriptions de flux reçues des unités de mesure et les descriptions de flux de paquets reçues des terminaux. La table ci-après détaille les informations ainsi regroupées. Table 5 Dans l'étape 32, dans un mode de réalisation de l'invention, selon la configuration de l'unité de collecte, cette dernière peut fournir : - des informations relatives au chemin des paquets du flux dans le réseau ; - des informations relatives à la gestion des équipements du chemin du flux dans le réseau ; - des informations relatives au traitement du flux dans les équipements du chemin ; - des informations de performance du réseau relatives à une perte de paquets sur un segment entre un des terminaux et un équipement ou entre deux équipements et/ou à un délai de transmission de paquets sur un segment entre un des terminaux et un équipement ou entre deux équipements et/ou à une variation de délai de transmission de paquets. Elle peut aussi calculer des délais de transmission de paquets et des pertes de paquets sur le chemin complet du flux, comme illustré dans les exemples décrits dans les sections suivantes. Dans un mode de réalisation de l'invention, l'unité de collecte fournit des vecteurs de NextHop de « bout en bout » en regroupant les informations de NextHop des paquets SYN et RST, à partir de l'étape (31).
Table 6 Dans un mode réalisation de l'invention, l'unité de collecte fournit des vecteurs d'interface de gestion, en regroupant les informations d'interface de gestion des paquets SYN et RST du flux de test, à partir de l'étape 31.
Table 7 Le vecteur final correspondant est donc {T11_AddrMgmt, ...,
Ei_AddrMgmt, Ei+1_AddrMgmt T12_AddrMgmt}. Dans un mode réalisation de l'invention, l'unité de collecte fournit des vecteurs d'AS, en regroupant les informations d'AS des paquets SYN et RST analysés et identifiés par l'unité de collecte, à partir de l'étape 31. L'AS de la source du flux et l'AS de la destination du flux sont respectivement décrites dans les champs exportés par les terminaux, Src_AS et Dst_AS. Une unité de mesure exporte, pour un équipement Ei donné, l'AS précédente dans le chemin et l'AS suivante dans le chemin c'est-à-dire l'AS du NextHop du flux. Le cas décrit ci-dessous s'avère être très utile dans un réseau IP pour un chemin de flux transitant par plusieurs AS différents. La connaissance de la liste des AS traversés par un flux permet d'établir un diagnostic inter-domaine. La table ci-après regroupe les informations des AS des paquets SYN et RST pour produire des vecteurs d'AS relatifs à des segments du chemin du flux.
Table 8 Le vecteur final correspondant est donc {T11_AS, ..., Ei-1_AS, Ei_AS, Ei+1_AS, Ei+2_AS,..., T12_AS). Dans un mode de réalisation de l'invention, l'unité de collecte fournit des vecteurs de Tos (ou encore QoS) en regroupant les informations des paquets SYN et RST, comme détaillée dans la table ci-après. Le champ Tos est un des rares champs qu'un équipement de réseau est autorisé à modifier. Ce champ détermine le niveau de qualité du traitement du paquet dans les files d'attente des équipements de réseau. C'est une information importante notamment en inter-domaine pour la mise en place de dispositifs de marquage de la qualité des services.
Table 9 Le vecteur final est donc {T11_Tos, ..., Ei_Tos, Ei+1_Tos,...,T12_ToS}. L'unité de collecte peut également calculer un vecteur de délai de transmission d'un paquet de « bout en bout » selon l'une des équations suivantes : T12_SYN_time - T11_SYN_time ; T12_RST_time - T11_RST_time. Les vecteurs de perte et de délai sont complémentaires. Un paquet observé par T12 permet de calculer un délai de transmission comme illustré dans la table ci-après.
Table 10
D'autre part, un paquet non observé permet de calculer une perte. Une perte d'un paquet SYN entre l'équipement Ei+1 et le terminal 12 est détectée comme illustrée par la table ci-après.
Table 11
Dans le cas illustré ci-dessus, le terminal 11 envoie un message d'ouverture de connexion TCP au terminal 12. Le paquet correspondant est observé par les équipements de réseau Ei, Ei+1... Ce message n'est visiblement pas reçu par le terminal 12. De ce fait, le terminal 11 ne reçoit pas de message d'accusé de réception correspondant. Ainsi, le message SYN est réémis par le terminal 11. Sur réception de ce second message SYN, les équipements de réseau considèrent qu'une nouvelle connexion, donc un nouveau flux, est à traiter. Une nouvelle entrée dans la table des caractéristiques de flux est alors créée. Dans le cas illustré par la table ci-dessous, une perte d'un paquet RST entre les équipements de réseau Ei et Ei+1 est détectée. Cette perte est confirmée par le fait que le paquet RST n'est pas reçu par T12.
Table 12 Ainsi, le segment Ei - Ei+1 du chemin complet qui a perdu le paquet est identifié. On notera que lorsqu'un flux est analysé par échantillonnage, les vecteurs instantanés fournis par l'unité de collecte sont moins précis et moins nombreux. En effet, dans de telles conditions, un paquet de test n'est pas systématiquement analysé par tous les routeurs. Toutefois, pour chaque flux de test, des mesures de « bout en bout » sont toujours disponibles. Par ailleurs, les connexions de type TCP franchissent les « murs pare- feu » (en anglais, « firewall ») des réseau IP. Ainsi, la présente invention basée sur un protocole de type TCP permet d'obtenir des mesures sur des chemins franchissant des murs pare-feu. Dans certains cas, il est avantageux d'introduire une unité de collecte comprenant deux modules dans l'architecture du réseau décrite précédemment. Par exemple, dans le cas où un module d'une unité de collecte est adaptée pour recevoir et gérer des descriptions de flux émises par les unités de mesure, mais n'est pas adaptée pour recevoir des descriptions de flux de paquets depuis les terminaux. On adjoint alors un autre module pour recevoir les descriptions de flux de paquets. La figure 3 illustre un procédé selon un mode de réalisation de l'invention dans une architecture du réseau basée sur une unité de collecte comprenant un premier et un second module. Le procédé comprend alors les étapes suivantes : - étape 302 : Envoi au terminal 11 et au second module 301 d'un message de demande de mise en copie des description de flux de test entre les terminaux 11 et 12, correspondant à une début de mesure, par le premier module 300; - étape 21 : Envoi du premier paquet correspondant à une demande de connexion TCP depuis le terminal 11 au terminal 12; - étape 22, 22' : Présentation du premier paquet au processus d'analyse du flux des unités de mesure des équipements Ei ; - étape 23, 23' : Création d'une nouvelle entrée dans la table des caractéristiques de flux gérée par les unités de mesure de flux des équipements Ei, à cette étape on stocke une référence temporelle de passage du premier paquet analysé dans le champ 'First' ; - étape 24 : Réception du premier paquet de demande de connexion par le terminal 12 et émission d'un message d'acquittement SYN-ACK par le terminal 12 à destination du terminal 11 ; - étape 25 : Réception du message d'acquittement SYN-ACK par le terminal 11 et envoie d'un message RST de fermeture de connexion TCP à
- destination du terminal 12 ; - étape 26 : Envoi de la description de flux de paquets par le terminal 11 vers le premier module 300; - étape 27, 27' : Détection de fin de flux sur réception du paquet RST et enregistrement d'une référence temporelle de passage de ce dernier paquet dans le champ 'Last' par les unités de mesure ; - étape 28, 28' : Exportation des descriptions de flux par les unités de mesure des équipements Ei vers le second module 301 ; - étape 29 : Réception du paquet de fermeture de connexion par le terminal 12 ; - étape 30 : Envoi de la description de flux de paquets par le terminal 12 vers le premier module 300; - étape 303 : Transmission au fil de l'eau des descriptions de flux entre les terminaux 11 et 12 par le second module 301 au premier module 300 ; - étape 304 : Regroupement et corrélation des données relatives à ce flux par le premier module 300; - étape 305 : Production des vecteurs des informations relatives à des équipements du chemin du flux ou à des segments du chemin empruntés par les paquets de ce flux ou encore relatifs au chemin complet par le premier module 300. De préférence, dans une configuration dans laquelle l'unité de collecte comprend deux modules 300 et 301 , le module 300 de l'unité de collecte comprend un filtrage en entrée permettant de filtrer seulement les informations relatives aux flux étudiés. Dans un mode de réalisation de l'invention, un ticket de description de flux comprend en outre un champ TTL', pour Time To Live. Une telle information est classiquement comprise dans un champ d'un paquet de flux. En exportant cette information, l'unité de collecte est ainsi capable d'ordonnancer très facilement les équipements Ei sur le chemin du flux. La présente invention s'avère être très avantageuse dans tous les domaines de la métrologie des réseaux de transmission de paquets, notamment pour le dimensionnement du réseau, ainsi que pour la mise en service et la maintenance du réseau et pour le contrôle de la qualité de service fournie. En effet, en cas de détection de problèmes de transmission « de bout en bout », un mode de réalisation de l'invention permet de localiser très rapidement le ou les segments du chemin complet qui sont à l'origine des problèmes, sur la base de mesures très précises et fiables relatives. En outre, les mesures fournies sont disponibles et exploitables très rapidement. De plus, un mode de réalisation de l'invention est très simple à mettre en œuvre dans des réseaux existants. On note en outre qu'il est aisé de déduire de la présente description un mode de réalisation de la présente invention dans lequel un terminal émet le flux de paquets à destination de plusieurs terminaux. Ainsi, le procédé de mesure selon un mode de réalisation de l'invention peut être appliqué aisément à une transmission à destination multiple, ou 'multicast' en anglais. Dans un tel cas, il est possible de prévoir que tout ou partie des terminaux récepteurs du flux de paquets émis envoie une description de flux de paquets reçus à l'unité de collecte. Dans le cas où l'unité de collecte reçoit plusieurs descriptions de flux de paquets reçus, elle peut par exemple en déduire le nombre de terminaux récepteurs qui ont effectivement reçu le flux diffusé en 'multicast'. Dans un autre mode de réalisation de la présente invention, la fonction de l'unité de collecte telle qu'énoncée précédemment peut être avantageusement remplie par une pluralité d'entités agencées dans une architecture hiérarchisée. Dans une telle architecture, une unité de collecte comprend une pluralité d'entités de collecte et une entité centrale. Le terminal et l'unité de mesure sont alors reliés à au moins une des entités de collecte. Ainsi, par exemple, un terminal peut envoyer des descriptions de flux de paquets à une des entités de collecte et l'une unité de mesure peut envoyer des descriptions de flux à une autre entité de collecte. Puis, chacune de ces entités de collecte peuvent ensuite transmettre les descriptions reçues à l'entité centrale, laquelle identifie chaque paquet analysé du flux en fonction de la description de flux pour corréler, paquet par paquet, la description de flux et la description de flux de paquets ainsi reçues.

Claims

REVENDICATIONS
1. Procédé de mesure dans un réseau de transmission de paquets de données, dans lequel un flux de paquets de données émis par un premier terminal (11) transite via au moins un équipement de réseau (13) auquel est associée une unité de mesure de flux, dans lequel ledit premier terminal, et ladite unité de mesure sont reliés à une unité de collecte (18), ledit procédé comprenant les étapes suivantes : le premier terminal génère un flux de paquets, comprenant un premier et un second paquets de contrôle d'état de session ; l'unité de mesure analyse ledit premier et/ou second paquet dudit flux, transitant par l'équipement de réseau ; le premier terminal envoie une description de flux de paquets émis comprenant au moins le nombre de paquets émis (26) à l'unité de collecte ; l'unité de mesure de flux envoie une description de flux (28,28') comprenant au moins une information indiquant le nombre de paquets analysés à l'unité de collecte ; et l'unité de collecte (18) identifie chaque paquet analysé du flux en fonction de la description de flux pour corréler, paquet par paquet, ladite description de flux et ladite description de flux de paquets émis.
2. Procédé selon la revendication 1 , dans lequel au moins un deuxième terminal (12) relié à l'unité de collecte (18) reçoit le flux de paquets et envoie une description de flux de paquets reçus, comprenant le nombre de paquets reçus, à l'unité de collecte ; et dans lequel l'unité de collecte identifie chaque paquet analysé pour corréler, paquet par paquet, la description de flux et les descriptions de flux de paquets.
3. Procédé selon la revendication 1 ou 2, dans lequel le terminal est un terminal mobile.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel le premier paquet est un paquet d'initiation de la connexion et le second paquet est un paquet de fermeture de la connexion.
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel le réseau de télécommunication est un réseau basé sur un protocole de type IP, pour 'Internet Protocol' ; dans lequel la connexion est une connexion TCP, pour Transmission Control Protocol' ; et dans lequel le premier paquet est un paquet SYN et le second paquet est un paquet RST ou un paquet FIN.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de collecte (18) détermine une perte de paquets relative à un segment entre le premier terminal et l'équipement par corrélation (32) du nombre de paquets émis et du nombre de paquets analysés.
7. Procédé selon l'une quelconque des revendications 2 à 6, dans lequel l'unité de collecte (18) détermine une perte de paquets relative à un segment entre l'équipement et le deuxième terminal par corrélation (32) du nombre de paquets analysés et du nombre de paquets reçus.
8. Procédé selon l'une quelconque des revendications 2 à 7, dans lequel les descriptions de flux de paquets (26,30) comprennent en outre une référence temporelle de l'émission par le premier terminal et/ou de la réception par le deuxième terminal, de chaque paquet du flux, et les descriptions de flux
(28,28') comprennent en outre une référence temporelle du passage par l'équipement du premier et du dernier paquet analysé, et dans lequel l'unité de collecte (18) détermine un délai de transmission desdits premier et dernier paquets analysés relatif à un segment entre un terminal et l'équipement par corrélation (32) desdites références temporelles des paquets.
9. Procédé selon l'une quelconque des revendications précédentes, dans lequel une pluralité d'équipements de réseau (13,15,16) sont prévus avec des unités de mesure respectives, et dans lequel l'unité de collecte (18) fournit au moins une des informations instantanées suivantes : des informations relatives au chemin des paquets du flux dans le réseau ; des informations relatives à la gestion des équipements du chemin du flux dans le réseau ; des informations relatives au traitement du flux dans les équipements du chemin ; des informations de performance relatives à une perte de paquets sur un segment entre un terminal et un équipement ou entre deux équipements; des informations de performance relatives à un délai de transmission de paquets sur un segment entre un terminal et un équipement ou entre deux équipements ; des informations de performance relatives à une variation de délai de transmission de paquets sur un segment entre un terminal et un équipement ou entre deux équipements.
10. Procédé selon la revendication 9, dans lequel l'unité de mesure fournit par itération des étapes du procédé selon la revendication 1 au moins une statistique des mesures suivantes relative à un segment entre un terminal et un équipement ou entre deux équipements : - une perte de paquets ; - un délai de transmission de paquets ; et - une variation de délai de transmission.
11. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de mesure analyse un sous ensemble de paquets du flux sélectionnés parmi les paquets du flux reçus par l'équipement.
12. Procédé selon la revendication 11 , dans lequel le sous-ensemble de paquets est sélectionné par échantillonnage du flux de paquets.
13. Procédé selon la revendication 11 ou 12, dans lequel l'unité de mesure fournit par itération des étapes du procédé selon la revendication 1 et par corrélation des informations obtenues à chaque itération, relativement à un segment entre un terminal et un équipement ou entre deux équipements, au moins une statistique des mesures suivantes: une perte de paquets; un délai de transmission de paquets ; et - une variation de délai de transmission.
14. Procédé selon la revendication 13, dans lequel on compare en outre la statistique avec les informations instantanées obtenues suivant le procédé selon la revendication 9, pour déterminer relativement rapidement des changements.
15. Procédé selon l'une quelconque des revendications 11 à 14, dans lequel l'unité de mesure fournit par itération des étapes du procédé selon la revendication 1 et par corrélation des informations obtenues à chaque itération au moins une des informations relativement précises suivantes : - des informations relatives au chemin des paquets du flux dans le réseau ; - des informations relatives à la gestion des équipements du chemin du flux dans le réseau ; - des informations relatives au traitement du flux dans les équipements du chemin ; des informations de performance relatives à. une perte de paquets sur un segment entre un terminal et un équipement ou entre deux équipements; - des informations de performance relatives à un délai de transmission de paquets sur un segment entre un terminal et un équipement ou entre deux équipements ; des informations de performance relatives à une variation de délai de transmission de paquets sur un segment entre un terminal et un équipement ou entre deux équipements.
16. Procédé selon la revendication 15, dans lequel on compare en outre les informations relativement précises avec les informations instantanées obtenues suivant le procédé selon la revendication 9, pour déterminer relativement rapidement des changements.
17. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de mesure est incluse dans l'équipement.
18. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de collecte (18) comprend un premier module (300) pour collecter les descriptions de flux de paquets et un second module (301) pour collecter les descriptions de flux ; dans lequel le second module (301) transmet les descriptions de flux au premier module (300) ; et dans lequel le premier module corrèle, paquet par paquet, les descriptions de flux et les descriptions de flux de paquets.
19. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'unité de collecte (18) comprend une pluralité d'entités de collecte et une entité centrale, le terminal et l'unité de mesure étant reliés à au moins une desdites entités de collecte ; et dans lequel les entités de collecte transmettent les descriptions de flux et les descriptions de flux de paquets reçues à ladite entité centrale, ladite entité centrale identifiant chaque paquet analysé du flux en fonction de la description de flux pour corréler, paquet par paquet, la description de flux et la description de flux de paquets.
20. Système de mesure dans un réseau de télécommunication de transmission de paquets de données comprenant des moyens agencés pour mettre en œuvre un procédé selon l'une quelconque des revendications de 1 à 19.
21. Unité de collecte comprenant des moyens agencés pour mettre en œuvre un procédé selon l'une quelconque des revendications 1 à 19.
EP05769213A 2004-05-07 2005-05-03 Mesure de performance dans un reseau de transmission de paquets Withdrawn EP1743453A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0404985 2004-05-07
PCT/FR2005/001114 WO2005112345A1 (fr) 2004-05-07 2005-05-03 Mesure de performance dans un reseau de transmission de paquets

Publications (1)

Publication Number Publication Date
EP1743453A1 true EP1743453A1 (fr) 2007-01-17

Family

ID=34945305

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05769213A Withdrawn EP1743453A1 (fr) 2004-05-07 2005-05-03 Mesure de performance dans un reseau de transmission de paquets

Country Status (3)

Country Link
US (1) US7869368B2 (fr)
EP (1) EP1743453A1 (fr)
WO (1) WO2005112345A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2324597A1 (fr) * 2008-07-21 2011-05-25 Satish Satya Vasamsetti Procédé et appareil de résolution de problèmes d abonnés dans un réseau de télécommunication
US10541933B2 (en) * 2016-11-10 2020-01-21 Disney Enterprises, Inc. Systems and methods for aligning frames of a digital video content in IP domain
US10587491B1 (en) * 2016-12-27 2020-03-10 Amazon Technologies, Inc. Testing computer networks in real time

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5477531A (en) 1991-06-12 1995-12-19 Hewlett-Packard Company Method and apparatus for testing a packet-based network
IL121898A0 (en) * 1997-10-07 1998-03-10 Cidon Israel A method and apparatus for active testing and fault allocation of communication networks
US6725378B1 (en) 1998-04-15 2004-04-20 Purdue Research Foundation Network protection for denial of service attacks
US6823381B1 (en) * 2000-08-17 2004-11-23 Trendium, Inc. Methods, systems and computer program products for determining a point of loss of data on a communication network
US7010598B2 (en) * 2002-02-11 2006-03-07 Akamai Technologies, Inc. Method and apparatus for measuring stream availability, quality and performance
US7200148B1 (en) * 2002-06-28 2007-04-03 Bellsouth Intellectual Property Corp. System and method for analyzing asynchronous transfer mode communications
KR100523486B1 (ko) * 2002-12-13 2005-10-24 한국전자통신연구원 트래픽 측정 시스템 및 그의 트래픽 분석 방법
US7263067B2 (en) * 2003-07-15 2007-08-28 Nokia Siemans Networks Oy Method and apparatus for accelerating throughput in a wireless or other telecommunication system
US7898969B2 (en) * 2004-05-07 2011-03-01 France Telecom Performance measurement in a packet transmission network
FR2870064A1 (fr) * 2004-05-07 2005-11-11 France Telecom Mesure de performance dans un reseau de transmission de paquets

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2005112345A1 *

Also Published As

Publication number Publication date
US20080137538A1 (en) 2008-06-12
US7869368B2 (en) 2011-01-11
WO2005112345A1 (fr) 2005-11-24

Similar Documents

Publication Publication Date Title
EP1743454B1 (fr) Mesure de performance dans un reseau de transmission de paquets
WO2005122473A1 (fr) Mesure de performance dans un reseau de transmission de paquets
CA2362923C (fr) Systeme et procede de mesure des durees de transfert et des taux de pertes dans des reseaux de telecommunication haut-debit
Kim et al. Application‐level traffic monitoring and an analysis on IP networks
TW536890B (en) Scalable real-time quality of service monitoring and analysis of service dependent subscriber satisfaction in IP networks
EP1453242A2 (fr) Sonde de mesure de paramètres de qualité de service pour un réseau de télécommunication
US20070019548A1 (en) Method and apparatus for data network sampling
EP1604487B1 (fr) Procede d' evaluation de la bande passante d' une liaison numerique
US20100265835A1 (en) System, method, and computer readable medium for measuring network latency from flow records
EP1521397A2 (fr) Localisation de points d'entree de flux dans un reseau de communications
FR2849559A1 (fr) Outil et methode d'analyse de chemin dans un reseau de transmission de donnees comprenant plusieurs systemes autonomes internet
He et al. Remote detection of bottleneck links using spectral and statistical methods
EP2090021A2 (fr) Procede de supervision d'une pluralite d'equipements dans un reseau de communication
WO2005112345A1 (fr) Mesure de performance dans un reseau de transmission de paquets
EP1605632A2 (fr) Corrélation de mesures passives de type bout-en-bout, au moyen de filtres hiérarchisés
Shi et al. Protocol-independent identification of encrypted video traffic sources using traffic analysis
Costeux et al. Qrp08-5: Detection and comparison of rtp and skype traffic and performance
JP2004032377A (ja) ボトルネック推定方法並びに装置および前記方法のプログラムを記録したコンピュータ読取り可能な記録媒体
EP1424832A1 (fr) Dispositif de mesures de bout en bout d'informations de reseau
Viipuri Traffic analysis and modeling of IP core networks
Callado et al. A Survey on Internet Traffic Identification and Classification
Meghdouri et al. Shedding light in the tunnel: Counting flows in encrypted network traffic
Bolla et al. Monitoring and Classification of Teletraffic in P2P Environment
Alouf Parameter estimation and performance analysis of several network applications
FR3131670A1 (fr) Protocole d’evaluation de congestion

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061110

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090417

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/721 20130101ALI20170216BHEP

Ipc: H04L 12/26 20060101ALI20170216BHEP

Ipc: H04L 12/24 20060101AFI20170216BHEP

INTG Intention to grant announced

Effective date: 20170309

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170720

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/24 20060101AFI20170216BHEP

Ipc: H04L 12/721 20130101ALI20170216BHEP

Ipc: H04L 12/26 20060101ALI20170216BHEP

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/24 20060101AFI20170216BHEP

Ipc: H04L 12/721 20130101ALI20170216BHEP

Ipc: H04L 12/26 20060101ALI20170216BHEP