EP4088429A1 - Routage de donnees dans un systeme de communication - Google Patents

Routage de donnees dans un systeme de communication

Info

Publication number
EP4088429A1
EP4088429A1 EP21707319.6A EP21707319A EP4088429A1 EP 4088429 A1 EP4088429 A1 EP 4088429A1 EP 21707319 A EP21707319 A EP 21707319A EP 4088429 A1 EP4088429 A1 EP 4088429A1
Authority
EP
European Patent Office
Prior art keywords
data
routing
router
node
message
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.)
Pending
Application number
EP21707319.6A
Other languages
German (de)
English (en)
Inventor
Marc Capelle
Sovatha Chou
Stéphane LITKOWSKI
Flavien JOLY POTTUZ
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
Orange 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 Orange SA filed Critical Orange SA
Publication of EP4088429A1 publication Critical patent/EP4088429A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/123—Evaluation of link metrics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H04L43/0835—One way packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/122—Shortest path evaluation by minimising distances, e.g. by selecting a route with minimum of number of hops
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering

Definitions

  • the present invention relates to a method for managing the routing of data in a data communication system, as well as to devices and software for implementing this method. It applies in particular to the measurement of the propagation time of routing information in a data communication system.
  • BGP Border Gateway Protocol
  • the “Border Gateway Protocol” (BGP) routing protocol is a routing protocol between autonomous systems designed to be implemented in TCP / IP type networks.
  • the BGP protocol is specified in the document “Request For Comments” initially n ° 1771 then updated under n ° 4271, entitled “A Border Gateway Protocol 4 (BGP-4)”, published by the organization “Internet Engineering Task Force ”(IETF).
  • One of the functions of the BGP protocol is to allow the exchange between two autonomous network accessibility information systems.
  • the information exchanged includes information on the list of autonomous systems that the accessibility information crosses, which makes it possible to construct a connectivity graph between the two autonomous systems, and to remove any routing loops from this graph. and to implement decision-making policies at the level of autonomous systems.
  • the implementation of decision policies using the BGP protocol is carried out by a mechanism of announcements sent by a node called "announcer" (in English, "BGP speaker”) to its corresponding nodes in autonomous systems neighbors of the routes that the advertiser node uses.
  • This mechanism is based on the principle of hop-by-hop routing currently used in the Internet network.
  • BGP is a routing protocol very widely used today in Internet networks. Its implementation within operator networks notably allows routing and accessibility information to be exchanged between operator networks, which constitute autonomous systems from the point of view of the BGP protocol.
  • the BGP protocol can be used to advertise Internet prefixes (typically IPv4 routes encoded on 4 bytes, or IPv6 routes encoded on 16 bytes) or virtual private network prefixes (in English "Virtual Private Network", or VPN), such as VPN-IPv4 routes encoded on 12 bytes, or VPN-IPv6 routes encoded on 24 bytes.
  • IPv4 Internet prefixes
  • VPN Virtual Private Network
  • An object of the present invention is to at least partially remedy the aforementioned drawbacks.
  • a method for measuring the propagation time of information relating to the routing of data in a data communication system comprising a data communication network comprising a plurality of router nodes operating according to a routing protocol for routing data packets between nodes of the data communication network, the method comprising, at a router node called a generator node: generating time-stamp data for the transmission of information relating to the routing of data; inserting the transmission timestamp data into a field of a routing protocol message carrying information relating to data routing, the field being intended to receive data relating to data routing; and send the message to another router node called a receiving node.
  • a method for measuring the propagation time of information relating to the routing of data in a data communication system comprising a data communication network comprising a plurality of router nodes operating according to a routing protocol for routing data packets between nodes of the data communication network, the method comprising, at a router node, called a receiving node: receiving a message from the routing protocol carrying information relating to the routing of data from another router node; extracting time stamp data from a field of the received message, the field being intended to receive data relating to the data routing; generate current time stamp data; and determining an estimate of the propagation time of the information relating to the data routing between the generating node and the receiving node, based on the message timestamp data and the current timestamp data.
  • the proposed methods deal among other things with a problem which has been identified by the inventors, according to which the speed to announce the creation, the modification or the withdrawal of an IP or VPN prefix is a criterion which becomes predominant in the choice of operational equipment which activates the BGP routing protocol.
  • a tool could be developed to identify / associate the prefixes that were generated with the information that was collected in order to be able to deduce the propagation time of the prefixes.
  • the proposed methods advantageously make it possible to estimate the propagation time of information relating to the routing of data, such as for example a data routing prefix, by minimizing the approximations as to the exact moment of the transmission of the. information, by inserting transmission timestamp data of information relating to the routing of data in a field of a routing protocol message used, such as for example the BGP protocol, then by sending the message .
  • the message destination router node can then, on receipt of a routing protocol message corresponding to the message sent, extract from a field of the message received the transmission timestamp data, and estimate the time of propagating the information relating to the data routing on the basis of the received time stamp data and current time stamp data.
  • the proposed methods do not require a complex implementation, in particular in that they do not require modifying the routing protocol used. They take advantage of this routing protocol by using a field in a routing protocol message to insert time stamp data. Any processing of the message by one or more intermediate router nodes is therefore not impacted by the proposed methods, which are therefore advantageously transparent for these intermediate node (s).
  • the proposed methods thus advantageously make it possible to measure precisely, without complexity of implementation, the propagation time of information relating to routing according to a routing protocol in a router or in a network.
  • the proposed method further comprises: extracting from the received message information relating to a router at the origin of the information relating to the routing of data, said generator node.
  • the timestamp data is inserted into the message as an Internet Protocol, IP address prefix, or a virtual private network, VPN prefix.
  • the routing protocol is the “Border Gateway Protocol”, BGP.
  • BGP defines different types of packets (OPEN, NOTIFICATION, UPDATE, KEEPALIVE, ...); only the BGP-UPDATE packet is responsible for announcing and removing routing information.
  • the transmission timestamp data is inserted into the "attribute" part, the "withdrawn” part or the "NLRI” part of the BGP-UPDATE message.
  • the transmission timestamp data is inserted into the "attribute" part (using a predefined attribute), the "withdrawn” part (as an Internet prefix or VPN), or the "NLRI” (as an Internet or VPN prefix) of the BGP-UPDATE message.
  • the routing protocol message is of the BGP-WITHDRAW type.
  • the routing protocol is the internal routing protocol "Intermediate System to Intermediate System", IS-IS (RFC 1142), or the internal routing protocol IP "Open Shortest Path First” , OSPF (RFC 2328 then RFC 5340).
  • a device comprising a processor and a radio-frequency unit operatively coupled to the processor, the device being configured for the implementation of a method according to one of the embodiments. proposed in the present description.
  • Another aspect relates to a computer program, loadable into a memory associated with a processor, and comprising portions of code for the implementation of a method as proposed in the present description during the execution of said. program by the processor.
  • Another aspect relates to a set of data representing, for example by compression or encoding, a computer program as proposed in the present description.
  • Another aspect relates to a non-transient storage medium for a computer executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, during the execution of said one or more programs by a computer comprising a processor operably coupled to a memory and to a data communication input / output interface, causing the computer to manage a data communication node according to a method of managing a data communication node. data communication according to one of the embodiments proposed in the present description.
  • FIG. 1 is a diagram illustrating an example of a system for implementing one or more embodiments of the proposed method
  • FIG. 2 is a diagram illustrating an example of the architecture of a router node for the implementation of one or more embodiments of the proposed method
  • FIG. 3a is a diagram illustrating a method proposed according to one or more embodiments
  • FIG. 3b is a diagram illustrating a method proposed according to one or more embodiments
  • FIG. 4 is a diagram illustrating an example of propagation delay measurements in a route reflector router in one or more embodiments of the proposed method
  • the present description refers to functions, motors, units, modules, platforms, and diagram illustrations of the methods and devices according to one or more embodiments.
  • Each of the functions, motors, modules, platforms, units and diagrams described can be implemented in hardware, software (including in the form of on-board software ("firmware"), or “middleware”), microcode, or any combination of these.
  • functions, motors, units, modules and / or diagram illustrations may be implemented by computer program instructions or software code, which may be stored or transmitted on a computer readable medium, including a non-transient medium, or a medium loaded in memory of a generic, specific computer, or of any other apparatus or programmable data processing device to produce a machine, so that the Computer program instructions or the software code executed on the computer or the programmable data processing device or device, constitute means of implementing these functions.
  • a computer readable medium include, but are not limited to, computer storage media and communication media, including any medium facilitating the transfer of a computer program from a location. to another.
  • computer storage medium any physical medium that can be accessed by a computer.
  • Examples of computer storage media include, but are not limited to, flash memory disks or components or any other flash memory devices (eg, USB keys, memory sticks, memory sticks, key disks), CD-ROMs or other optical data storage devices, DVDs, magnetic disk data storage devices or other magnetic data storage devices, data memory components, RAM, ROM, EEPROM, memory cards ("smart cards”), memories of the SSD type (“Solid State Drive”), and any other form of support which can be used to transport or store or memorize data or data structures which can be read by a processor. computer.
  • various forms of computer readable medium can transmit or carry instructions to a computer, such as a router, a gateway, a server, or any data transmission equipment, whether it is wired transmission (by coaxial cable, optical fiber, telephone wires, DSL cable, or Ethernet cable), wireless (by infrared, radio, cellular, microwave), or virtualized transmission equipment (virtual router, virtual gateway, end of virtual tunnel, virtual firewall).
  • a computer such as a router, a gateway, a server, or any data transmission equipment, whether it is wired transmission (by coaxial cable, optical fiber, telephone wires, DSL cable, or Ethernet cable), wireless (by infrared, radio, cellular, microwave), or virtualized transmission equipment (virtual router, virtual gateway, end of virtual tunnel, virtual firewall).
  • the instructions may, depending on the embodiments, include code of any computer programming language or computer program element, such as, without limitation, assembly languages, C, C ++, Visual Basic, HyperText Markup Language (HTML), Extensible Markup Language (XML), HyperText Transfer Protocol (HTTP), Hypertext Preprocessor (PHP), SQL, MySQL, Java, JavaScript, JavaScript Object Notation (JSON), Python, and bash scripting.
  • HTML HyperText Markup Language
  • XML Extensible Markup Language
  • HTTP HyperText Transfer Protocol
  • PHP Hypertext Preprocessor
  • SQL SQL
  • MySQL Java, JavaScript, JavaScript Object Notation
  • Python Python
  • bash scripting any computer programming language or computer program element
  • server or “platform” is meant in the present description any point of service (virtualized or not) or device operating data processing, one or more databases, and / or communication functions. data.
  • server or the term “platform” can refer to a physical processor operably coupled with associated communication, database and data storage functions, or make reference to a network, group, set or complex of processors and associated data storage and networking equipment, as well as an operating system and one or more database system (s) and application software in support of the services and functions provided by the server.
  • a computing device can be configured to send and receive signals, by wireless and / or wired transmission network (s), or can be configured for processing and / or storage of data or signals, and can therefore function as a server.
  • equipment configured to operate as a server may include, by way of non-limiting examples, dedicated rack-mounted servers, desktops, laptops, service gateways (sometimes referred to as “boxes” or " residential gateway ”), multimedia decoders (sometimes called“ set-top boxes ”), integrated equipment combining various functionalities, such as two or more of the functionalities mentioned above.
  • Servers can vary widely in their configuration or capabilities, but a server will typically include one or more central processing unit (s) and memory.
  • a server can also include one or more mass memory equipment (s), one or more power supply (s), one or more wireless and / or wired network interface (s), one or more several input / output interface (s), one or more operating system (s), such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or an equivalent.
  • network and “communication network” as used in the present description refer to one or more data links which can couple or connect equipment, possibly virtualized, so as to allow the transport of data.
  • electronic devices between computer systems and / or modules and / or other electronic devices or equipment such as between a server and a client device or other types of devices, including between wireless devices coupled or connected by a wireless network, for example.
  • a network can also include a mass memory for storing data, such as a NAS (in English "network attached storage", a SAN (in English “storage area network”), or any other form of media readable by a computer. or by a machine, for example.
  • a network can comprise, in whole or in part, the Internet network, one or more local area networks (or LANs), one or more WAN type networks (in English Wide area networks), wired type connections, wireless type connections, cellular type, or any combination of these different networks.
  • subnets may use different architectures or be compliant or compatible with different protocols, and interoperate with larger networks. Different types of equipment can be used to make different architectures or protocols interoperable. For example, a router can be used to provide communication link or a data link between two LANs that would otherwise be separate and independent.
  • an operative coupling may include one or more wired connection (s) and / or one or more wireless connection (s) between two or more devices that allow simplex and / or duplex communication links. between the equipment or portions of the equipment.
  • an operational coupling or connection may include a wired and / or wireless link coupling to allow data communications between a server of the proposed system and other equipment of the system.
  • app or “application program” (AP) and their variants (“app”, “webapp”, etc.) as used in the present description correspond to any tool which functions and is operated by means of from a computer, to provide or execute one or more function (s) or task (s) for a user or another application program.
  • a user interface may be provided on the equipment on which the application program is implemented.
  • GUI graphical user interface
  • an audio user interface can be rendered to the user using a loudspeaker. , headphones or audio output.
  • BGP protocol is meant a routing protocol in accordance with the RFC 1771 specification then RFC 4271 and / or any other prior and / or corresponding specification, as published by the IETF or by any other organization or standardization group, and / or their evolutions.
  • the three routers RTR1 (10a), RTR2 (10b) and RTR3 (10c) illustrated in the figure can therefore be routers activating the BGP protocol and therefore capable of exchanging messages of the BGP protocol and of implementing the functionalities defined for the BGP protocol.
  • RTR1 (10a), RTR2 (10b) and RTR3 (10c) routers can be connected to devices (l ia, 11b, 11c, l ld, l ie, l lf, 11g) which do not activate the BGP protocol, such as set-top boxes, boxes, switches, computers, user equipment (tablets, etc.).
  • each of the routers of the network (1) can be configured to operate in “BGP announcer” mode (in English, “BGP speaker”) as defined by RFC 1771 then RFC 4271. In this mode, when a router (e.g. router RTR1 (10a), in Figure 1) receives an external route for routing data and is selected as the best path for that data, it must advertise this information to other routers in the network (for example the routers RTR2 and RTR3 of the network (1) in FIG. 1).
  • the advertiser router RTR1 must announce its information to each of the other routers, RTR2 and RTR3 in the example of FIG. 1 , which leads to the use of communication resources between each pair of routers RTR1-RTR2 and RTR1-RTR3.
  • the network can use one or more of the route reflection functions (in English, "route reflection ”) described in RFC 4456 published by the IETF, entitled“ BGP Route Reflection - An Alternative to Full Mesh IBGP ”.
  • the route reflector function typically makes it possible to avoid the interconnection of a large number of routers according to a mesh network architecture in which the routers are for example interconnected two by two .
  • the RR node thus avoids the scale problems that arise when a large number of routers all need to receive external routing information.
  • Route reflection thus makes it possible to avoid the implementation of a mesh network type architecture, by the implementation within one of the routers of the network (1) of a route reflector function (in English , “Route reflector”, or “RR”) as defined in RFC 4456.
  • the network architecture can then provide that one of the network router nodes will operate in RR node mode, in which case the RR node will be configured to exchange data with each of the other router nodes in the network.
  • the number of routers connected to an RR node could reach several hundred, which shows the advantage that there can be in using an RR node.
  • the RR node can be configured to implement one or more of the functions specified in RFC 4456.
  • a network comprising a plurality of routers ( RTR1, 10a; RTR2, 10b, RTR3, 10c) can use an RR node (RTR2, 10b) in order to implement the distribution of external routing information to all routers in the network through the RR node (RTR2, 10b ).
  • RTR1, 10a; RTR2, 10b, RTR3, 10c can use an RR node (RTR2, 10b) in order to implement the distribution of external routing information to all routers in the network through the RR node (RTR2, 10b ).
  • RTR2, 10b RR node
  • the router node RR RTR2 (10b) can thus provide an interface between all the routers RTR1 (10a), RTR3 (10c) of the network (2), these routers only having to establish a data communication session with the router node RR RTR2 (10b).
  • each router RTR1 (10a), RTR3 (10c) other than the router node RR RTR2 (10b) may have previously established a data communication session with the router node RR RTR2 (10b) for the exchange of routing protocol messages with this router node RR RTR2 (10b).
  • the RR function may be implemented, in whole or in part, within one of the router nodes of the network, and / or in whole or in part within another type of network. network node.
  • the network (2) formed by the router nodes may be of any type of data communication network, such as for example a packet data network (in English, " Packet Data Network ”, or PDN), and include one or more data transmission networks of the IP network (standing for“ Internet Protocol ”), and use communication links based on the TCP, IP, and / or any type of protocol that can be used for data communication in a data communication network.
  • the network (2) may use one or more routing protocols, such as for example the BGP protocol, the ISIS protocol, and / or the OSPF protocol.
  • each router node (10) of the network may include a data communication unit (20), a controller (21), a routing unit (22), and a propagation time measurement unit (23).
  • the data communication unit (20), the routing unit (22), and the propagation time measurement unit (23) may be operably coupled to the controller (21). by a communication bus (24), or by any communication link, optionally comprising one or more hardware connectors.
  • a communication bus 24
  • any communication link optionally comprising one or more hardware connectors.
  • the set of data communication units (20), controller (21), routing unit (22), propagation time measurement unit (23 ), functional unit (24) and communication bus (24) form a router node according to one or more embodiments, which may furthermore include other components, units, functions, not shown in the figure.
  • the controller (21) may include one or more processors, such as microprocessor, microcontroller or other hardware processor, associated memory (eg, random access memory (RAM), cache memory, flash memory, etc. ), and be able to be configured to drive the data communication unit (20), the routing unit (22), the delay measurement unit (23), in order to control the use of the router node (10) according to one or more embodiments of the proposed method, for example by executing a computer program comprising portions of code for the implementation of a method for measuring the propagation time of information relating to the routing of data as proposed in the present description.
  • an associated memory of the controller (21), external or internal to the controller (21) contains instructions which, when executed by the controller (21), cause this controller (21) to perform.
  • the controller (21) can be a component implementing a processor or a calculation unit for measuring the propagation time of information relating to the routing of data according to the proposed method and the control of the propagation time measurement unit.
  • the propagation time measurement unit (23) can be implemented, depending on the embodiment chosen, in the form of one or more software, or a combination of one or more hardware and one or more software, configured for the implementation of embodiments of the management method described in the present description.
  • the router node (10) can be configured via the propagation time measurement unit (23) to operate according to a plurality of operating modes, among which is a so-called “generator node” operating mode. and a so-called “receiver node” operating mode, and to operate in generator node mode and / or in receiver node mode according to one or more embodiments described in the present description.
  • the software part of the propagation time measurement unit (23) can constitute or form part of a software for controlling the router node (10).
  • the term “driver” will denote a set of one or more software configured for the implementation of a method for measuring the propagation time of information relating to the device. data routing as proposed in the present description.
  • the driver software is configured to be executable on a processor of the router node, and / or on a processor of computer equipment to which part of the router node is connected.
  • the data communication unit (20) can be implemented, depending on the embodiment chosen, in the form of a combination of one or more hardware and one or more software, and include a or more wired communication equipment, radiofrequency and / or optical, and a communication unit control software, for example executable by the controller (21) or, in another architecture of the communication node, executable by a processor of the data communications unit (20), and loaded into memory accessible by a processor configured to run communications unit driver software.
  • the data communication unit (20) may include a data communication interface.
  • the routing unit (22) can be implemented, depending on the embodiment chosen, in the form of a combination of one or more hardware and one or more software, and include one or more routing protocol management units, for example executable by the controller (21) or, in another architecture of the router node, executable by a processor of the routing unit (22), and loaded into a memory accessible by a processor configured to run the routing unit driver software.
  • the routing unit (22) could be configured to implement one or more of the functionalities of a routing protocol, such as the BGP protocol, the ISIS protocol, and / or the OSPF protocol.
  • the router node device (10) can be implemented in software form, in which case it takes the form of a program executable by a processor, or in hardware form (or “hardware”), such as a specific integrated circuit application (ASIC), a system on chip (SOC), or in the form of a combination of hardware and software elements, such as for example a software program intended to be loaded and executed on an FPGA (Field Programmable Gâte Array) type component. ).
  • SOC System On Chip
  • system on chip are embedded systems that integrate all the components of an electronic system into a single chip.
  • An ASIC Application-specific Integrated Circuit
  • Programmable logic circuits of the FPGA (Field-Programmable Gâte Array) type are electronic circuits that can be reconfigured by the user.
  • the router node device (10) can also use hybrid architectures, such as for example architectures based on a CPU + FPGA, a GPU (Graphics Processing Unit) or an MPPA (Multi-Purpose Processor Array).
  • hybrid architectures such as for example architectures based on a CPU + FPGA, a GPU (Graphics Processing Unit) or an MPPA (Multi-Purpose Processor Array).
  • router node device (10) can be adopted, both for the hardware part of the device, and for the software part of the device, if applicable.
  • the proposed method is not limited to a particular architecture of the router node (10), of the data communication unit (20), of the controller (21), of the routing unit (22), of the propagation time measurement unit (23) and of the communication bus (25), or of the coupling between these elements illustrating by way of example an embodiment in FIG. 2.
  • Described below are methods of measuring the propagation time of data routing information in a data communication system such as that illustrated in Figures 1 and 2, in one or more embodiments.
  • At least one of the communication nodes (RTR2, 10b) of the system (1) can be configured to operate in router mode RR, and another router node of the system (1) (RTR1, 10a) can be configured to generate (40) time stamp data for the transmission of information relating to the data routing, and insert (41) the transmission timestamp data in a field of a message of the BGP routing protocol, the field being intended to receive data relating to the routing of data.
  • the router node RTR1 (10a) can then send (42) the message to the router node RR RTR2 to announce to the other routers of the network (2) the information relating to the routing of data carried by the message.
  • the protocol message used for the implementation of the proposed method can be, depending on the embodiment, of the “UPDATE” type or of the “WITHDRAWN” type. .
  • the router node RTR1 thus sends time-stamping data in the form of routing information as part of the advertisement of the routing information to the other routers of the network to which the routing information must be announced according to the protocol of routing used.
  • the router node RR RTR2 (10b) On receipt of the message from the router node RTR1 (10a), the router node RR RTR2 (10b) performs the processing necessary to transmit the routing information contained in the message to the other router nodes of the network (2), and in particular the router node RTR3 (10c).
  • the RTR3 node (10c) can be configured for, on receipt (50) of a routing protocol message from another router node, for example the router node RR RTR2 (10b) in the example of network illustrated in FIG. 1, extracting (51) from a field of the message received time-stamping data, the field being intended to receive data relating to the routing of data.
  • the time stamp data may correspond to that inserted by the router node RTR1 (10a) in a field of the routing protocol message sent to the router node RR RTR2 (10b).
  • the router node RTR3 (10c) can therefore be configured as a receiving node to perform measurements of the processing and propagation time of a routing protocol message sent by another router node, configured to function as a node sending test messages. , by a router or a network of routers subject to the test.
  • the receiving router node can be configured (for example preconfigured) to identify, among the messages received or among the different types of messages received, those used by the sending router node to insert transmission time stamp information therein.
  • the sending router node can be configured (for example preconfigured) to insert a timestamp information in a predefined protocol message or of a predefined type (for example one or more messages of the UPDATE and / or WITHDRAW type for the BGP routing protocol), according to a test configuration corresponding to that used to configure the receiving router node.
  • a predefined protocol message or of a predefined type for example one or more messages of the UPDATE and / or WITHDRAW type for the BGP routing protocol
  • the RTR3 node (10c) can also be configured to extract from the message received information relating to a router at the origin of said information relating to the routing of data, either in the example of figure 1 extract from the message received a information making it possible to identify the router node RTR1 (10a) at the origin of the received message (and therefore of the timestamp data that it contains).
  • the router node RTR3 (10c) can further be configured to generate (52) current timestamp data, then determine (53) an estimate of the propagation time of the information. routing between the message-originating router and the message-destination router (i.e. router node RTR3 (10c) itself), based on a difference between the data of timestamp extracted from the message and the current timestamp data.
  • the destination router node of the message, RTR3 (10c) can be configured for, upon receipt of the message from the router node RTR1 (10a) via the router node RR RTR2 (10b), estimate a message propagation time, this propagation time comprising the propagation of the message from the originating router of the message, RTR1 (10a) to the destination router, RTR3 (10c) and the processing of the message by the intermediate node RTR2 (10b).
  • the destination router node RTR3 (10c) can thus advantageously measure the cumulative time necessary for the router node RR RTR2 (10b), to process the message, once received from the original router node RTR1 (10a) and to retransmit it. to all the other router nodes of the network (2).
  • the BGP messages of the UPDATE type or of the WITHDRAWN type may be used in one or more embodiments.
  • the timestamp data may be in a floating number format on 32 bits, with the integer part representing the number of seconds elapsed since 01/01/1970 and the decimal part representing the number. microseconds to add to the number of seconds.
  • the BGP protocol defines BGP messages of the UPDATE type in order, among other things, to announce and / or withdraw information relating to routing, such as accessibility information, such as for example a prefix.
  • UPDATE type BGP messages include four distinct parts, including a header, a "Paths Attributes” part, and a “withdrawal” part. , “Withdrawn") and an "NLRI” part (from the English “Network Layer Reachability Information”)
  • the "path attribute” part can be used to indicate the list of properties associated with the routing information (for example to the prefix).
  • the "withdrawal” part can be used to indicate accessibility information, such as a set of prefixes to be withdrawn.
  • the “NLRI” part can be used to indicate prefixes to be created / modified and to which we associate the attribute (s) indicated in the “attribute” part.
  • attribute type “ORIGIN” to define the origin of the routing information
  • type mandatory attribute “AS-PATH” to define a series of autonomous system route segments
  • mandatory attribute type “NEXT HOP” to define the IP address of a border router
  • optional attribute type “MULTI EXIT DISC” to define different exit points of an autonomous system
  • the discretionary attribute type "LOCAL PREF” to inform the routers of an autonomous system of the degree of preference of an announcing router for an advertised route
  • timestamp type information can be inserted, in the form of timestamp data, in a BGP protocol message, for example in an UPDATE type message.
  • the timestamp data may be inserted into a BGP UPDATE message field intended to receive data representing information relating to the routing of data, such as for example prefix data (for example IP address prefix or VPN prefix).
  • prefix data for example IP address prefix or VPN prefix.
  • the timestamp data can be inserted into an UPDATE message field corresponding to the "attribute" part.
  • time stamp data can be inserted as an attribute with an already existing attribute type, such as the optional type "LOCAL PREF".
  • an attribute type having a format compatible with that of the timestamp data to be transmitted can be used to transmit this data in a BGP UPDATE message.
  • the time stamp data is then transmitted in an UPDATE message as an attribute of the "LOCAL PREF" type.
  • the timestamp data may be inserted into an UPDATE message field corresponding to the "withdrawal" part.
  • time stamp data can be inserted as an Internet or VPN prefix.
  • the "withdrawal" field being used to indicate a list of IP address prefixes for the routes which are withdrawn from service, it is possible to transmit timestamp data having a format compatible with that of one or more prefixes. 'IP address by inserting this data as one or more IP address prefixes in a BGP UPDATE message.
  • the time stamp data is then transmitted in the "withdrawal" field of an UPDATE message as the IP address prefix (s).
  • the timestamp data can be inserted in an UPDATE message field corresponding to the "NLRI" part.
  • the time stamp data can be inserted as an Internet or VPN prefix.
  • the "NLRI" field being used to indicate a list of IP address prefixes, it is possible to transmit data. timestamp having a format compatible with that of one or more IP address prefixes by inserting this data as one or more IP address prefixes in a BGP UPDATE message.
  • the timestamp data is then transmitted in the "NLRI" field of an UPDATE message as the IP address prefix (s).
  • a BGP router called “generator” router or “original” router, generates a BGP message of the UPDATE type, and inserts transmission timestamp data into the message.
  • BGP UPDATE as an attribute in the "attribute” part, as an IP address prefix or VPN prefix in the "withdrawal” part, and / or as an IP address prefix or VPN prefix in the "part” NLRI ”.
  • the generating BGP router then sends the BGP UPDATE message to the router (for example an RR router) or to the network whose propagation time is to be measured (including the processing time).
  • Said router or network performs the processing necessary to take into account the information contained in the BGP UPDATE message sent by the “generator” router, and propagate this message to its neighbors after having carried out the required processing.
  • One of the routers receiving the message from said router or network is configured to extract the time stamp data from the received message.
  • the generator router is configured to insert transmission timestamp data in a BGP UPDATE message as an attribute in the "attribute” part, as an address prefix IP or VPN prefix in the "withdrawal” part, and / or as an IP address prefix or VPN prefix in the "NLRI” part
  • the receiving router will be, correspondingly, configured to extract these timestamp data from '' a received BGP UPDATE message, as an attribute of the "attribute” part, as an IP address prefix or VPN prefix of the "withdrawal” part, and / or as an IP address prefix or VPN prefix of the "NLRI” part , respectively.
  • the receiving router can then compare the received timestamp data with its own timestamp, to deduce the propagation time (including processing time) necessary for said router or network.
  • FIG. 4 illustrates an example of propagation time measurements in an RR router in one or more embodiments.
  • the test generator router executes an infinite loop routine, each loop instance comprising (1) the execution of ten instances of a loop for generating and sending a BGP UPDATE message containing timestamp data in the field "Route Distinguisher" (which an element of a VPN-IPv4 or VPN-IPv6 route) of the BGP UPDATE message, with a predetermined interval (for example 0.5 s) between each instance, (2) a predetermined waiting time (e.g.
  • the BGP test generator router therefore sends almost permanently to an RR router, the processing and propagation time of which one seeks to measure, 10 UPDATE messages which contain route modifications and time stamp data.
  • the router RR processes each of these messages, and advertises them to a BGP test receiving router.
  • the BGP test receiver router is configured to receive BGP UPDATE messages from the RR router, extract timestamp data from each received BGP UPDATE message from the "Route Distinguisher" field of the message, and determine a processing time measurement. and propagating to the RR router from its own timestamp and the received timestamp data.
  • the test generator router executes an infinite loop routine, each loop instance comprising (1) the execution of ten instances of a loop for generating and sending a BGP WITHDRAW message containing timestamp data in the “Route Distinguisher” field of the BGP WITHDRAW message, with a predetermined interval (for example 0.5 s) between each instance, (2) a predetermined waiting time (for example 10 s), (3) the execution of ten other loop instances of generating and transmitting a BGP WITHDRAW message containing timestamp data in the "Route Distinguisher” field of the BGP WITHDRAW message, with a predetermined interval (e.g. 0 , 5 s) between each instance, and (4) a predetermined waiting time (for example 10 s).
  • a predetermined interval for example 0.5 s
  • a predetermined waiting time for example 10 s
  • the BGP test generator router therefore sends almost permanently to an RR router, the processing and propagation time of which is sought to measure 10 WITHDRAW messages which contain route modifications and timestamp data.
  • the router RR processes each of these messages, and advertises them to a BGP test receiving router.
  • the BGP test receiving router is configured to receive BGP WITHDRAW messages from the RR router, extract timestamp data from each received BGP WITHDRAW message from the "Route Distinguisher" field of the message, and determine a processing time metric. and propagation required by the RR router to remove a route from its own timestamp and received timestamp data.
  • the proposed method provides a solution for measuring propagation time in a router or in a network using a routing protocol which is advantageously simple to implement, in particular in that it does not require additional developments on the system. routing protocol.
  • the proposed method can thus be implemented by software, independently, that is to say without depending on a particular implementation of the routing protocol or on a proprietary equipment on which it is implemented.
  • the proposed method also advantageously involves a low cost of calculations, so that it can be implemented in parallel with other tests to see the impact of these other tests on the propagation time measured by the device. proposed process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procédé de mesure du temps de propagation d'une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur dit nœud générateur : générer des données d'horodatage d'émission de l'information relative au routage de données; insérer les données d'horodatage d'émission dans un champ d'un message du protocole de routage porteur de l'information relative au routage de données, le champ étant destiné à recevoir des données relatives au routage de données; et envoyer le message à un autre nœud routeur dit nœud récepteur.

Description

Procédé de gestion du routage de données dans un système de communication et dispositifs pour la mise en œuvre du procédé
[0001] La présente invention se rapporte à un procédé de gestion du routage de données dans un système de communication de données, ainsi qu’à dispositifs et logiciels pour la mise en œuvre de ce procédé. Elle s’applique notamment à la mesure du temps de propagation d’une information de routage dans un système de communication de données.
[0002] Le protocole de routage « Border Gateway Protocol » (BGP) est un protocole de routage entre systèmes autonomes conçu pour être mis en œuvre dans des réseaux de type TCP/IP. Le protocole BGP est spécifié dans le document « Request For Comments » initialement n° 1771 puis mis à jour sous le n°4271, intitulé « A Border Gateway Protocol 4 (BGP-4) », édité par l’organisation « Internet Engineering Task Force » (IETF).
[0003] Une des fonctions du protocole BGP est de permettre l’échange entre deux systèmes autonomes d’information d’accessibilité de réseau. L’information échangée comprend de l’information sur la liste des systèmes autonomes que l’information d’accessibilité traverse, ce qui permet de construire un graphe de connectivité entre les deux systèmes autonomes, et de supprimer de ce graphe les éventuelles boucles de routage et de mettre en œuvre des politiques de décision au niveau des systèmes autonomes.
[0004] La mise en œuvre de politiques de décision en utilisant le protocole BGP s’effectue par un mécanisme d’annonces envoyées par un nœud dit « annonceur » (en anglais, « BGP speaker ») à ses nœuds correspondants dans des systèmes autonomes voisins des routes que le nœud annonceur utilise. Ce mécanisme repose sur le principe du routage par sauts (en anglais, « hop-by-hop ») actuellement utilisé dans le réseau Internet.
[0005] Le protocole BGP est un protocole de routage très largement utilisé aujourd’hui dans les réseaux de l’Internet. Sa mise en œuvre au sein des réseaux opérateurs permet notamment d’échanger des informations de routage et d’accessibilité entre les réseaux des opérateurs, qui constituent des systèmes autonomes du point de vue du protocole BGP. Par exemple, le protocole BGP peut être utilisé pour annoncer des préfixes Internet (typiquement des routes IPv4 codées sur 4 octets, ou des routes IPv6 codées sur 16 octets) ou des préfixes de réseau privé virtuel (en anglais « Virtual Private Network », ou VPN), comme par exemple des routes VPN-IPv4 codées sur 12 octets, ou des routes VPN-IPv6 codées sur 24 octets.
[0006] Cependant, l’utilisation de protocoles de routage tels que le protocole BGP dans des réseaux à forte densité de nœuds nécessite d’avoir des outils de mesure de performance afin d’optimiser les choix de mise en œuvre de ces protocoles, notamment sur les réseaux opérés par des opérateurs télécoms. [0007] Un objet de la présente invention est de remédier au moins partiellement aux inconvénients précités.
[0008] Selon un premier aspect, il est proposé un procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur dit nœud générateur : générer des données d’horodatage d’émission de l’information relative au routage de données ; insérer les données d’horodatage d’émission dans un champ d’un message du protocole de routage porteur de l’information relative au routage de données, le champ étant destiné à recevoir des données relatives au routage de données ; et envoyer le message à un autre nœud routeur dit nœud récepteur.
[0009] Selon un autre aspect, il est proposé un procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur, dit nœud récepteur : recevoir un message du protocole de routage porteur de l’information relative au routage de données en provenance d’un autre nœud routeur ; extraire d’un champ du message reçu des données d’horodatage, le champ étant destiné à recevoir des données relatives au routage de données; générer des données d’horodatage courant ; et déterminer une estimation du temps de propagation de l’information relative au routage de données entre le noeud générateur et le noeud récepteur, sur la base des données d’horodatage du message et des données d’horodatage courant.
[0010] Les procédés proposés traitent entre autres d’une problématique qui a été identifiée par les inventeurs, selon laquelle la vitesse pour annoncer la création, la modification ou le retrait d’un préfixe IP ou VPN est un critère qui devient prépondérant dans le choix des équipements opérationnels qui activent le protocole de routage BGP.
[0011] Pour mesurer le temps de propagation d’un préfixe VPN dans un routeur ou dans un réseau (comprenant un ensemble de routeurs), il serait envisageable d’utiliser un générateur de préfixes IP ou VPN et un analyseur de trafic. En synchronisant ces deux équipements/outils, un outil pourrait être développé pour identifier/associer les préfixes qui ont été générés avec les informations qui ont été collectées pour pouvoir en déduire le temps de propagation des préfixes.
[0012] Cette possibilité serait complexe à mettre en œuvre. De plus, outre la complexité de mise en œuvre, il resterait des approximations quant au moment exact de l’émission d’un préfixe, et donc des incertitudes sur les résultats obtenus. [0013] Les procédés proposés permettent avantageusement d’ estimer le temps de propagation d’une information relative au routage de données, comme par exemple un préfixe de routage de données, en minimisant les approximations quant au moment exact de l’émission de l’information, par l’insertion de données d’horodatage d’émission d’une information relative au routage de données dans un champ d’un message de protocole de routage utilisé, comme par exemple le protocole BGP, puis par l’envoi du message.
[0014] Le nœud routeur de destination du message peut alors, sur réception d’un message de protocole de routage correspondant au message envoyé, extraire d’un champ du message reçu les données d’horodatage d’émission, et estimer le temps de propagation de l’information relative au routage de données sur la base des données d’horodatage reçues et de données d’horodatage courant.
[0015] Dès lors, que ce soit au niveau du routeur générant les données d’horodatage d’émission d’information relative au routage de données ou au niveau du routeur recevant ces données d’horodatage et les traitant pour estimer un temps de propagation de l’information relative au routage de données, un ou plusieurs messages de protocole de routage sont utilisés sans que les procédés proposés nécessitent des changements ou des développements supplémentaires du protocole de routage utilisé.
[0016] Ainsi, avantageusement, les procédés proposés ne requièrent pas une mise en œuvre complexe, notamment en ce qu’ils ne nécessitent pas de modifier le protocole de routage utilisé. Ils tirent parti de ce protocole de routage en utilisant un champ d’un message du protocole de routage pour y insérer des données d’horodatage. Les éventuels traitements du message par un ou plusieurs nœuds routeurs intermédiaires ne sont donc pas impactés par les procédés proposés, qui sont donc avantageusement transparents pour ce(s) nœud(s) intermédiaire(s).
[0017] Les procédés proposés permettent ainsi avantageusement de mesurer précisément, sans complexité de mise en œuvre, le temps de propagation d’une information relative au routage selon un protocole de routage dans un routeur ou dans un réseau.
[0018] Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres :
[0019] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : extraire du message reçu une information relative à un routeur à l'origine de l’information relative au routage de données, dit nœud générateur.
[0020] Dans un ou plusieurs modes de réalisation, les données d’horodatage sont insérées dans le message en tant que préfixe d’adresse Internet Protocol, IP, ou préfixe de réseau privé virtuel, VPN. [0021] Dans un ou plusieurs modes de réalisation, le protocole de routage est le protocole « Border Gateway Protocol », BGP. BGP définit différents types de paquets (OPEN, NOTIFICATION, UPDATE, KEEPALIVE, ...) ; seul le paquet BGP-UPDATE est responsable de l’annonce et du retrait d’informations de routage. Dans un ou plusieurs modes de réalisation, les données d’horodatage d’émission sont insérées dans la partie « attribut », la partie « withdrawn » ou la partie « NLRI » du message BGP-UPDATE. Dans un ou plusieurs modes de réalisation, les données d’horodatage d’émission sont insérées dans la partie « attribut » (en utilisant un attribut prédéfini), la partie « withdrawn » (en tant que préfixe Internet ou VPN), ou la partie « NLRI » (en tant que préfixe Internet ou VPN) du message BGP-UPDATE.
[0022] Dans un ou plusieurs modes de réalisation, le message du protocole de routage est du type BGP-WITHDRAW.
[0023] Dans un ou plusieurs modes de réalisation, le protocole de routage est le protocole de routage interne « Intermediate System to Intermediate System », IS-IS (RFC 1142), ou le protocole de routage interne IP « Open Shortest Path First », OSPF (RFC 2328 puis RFC 5340).
[0024] Selon un autre aspect, il est proposé un dispositif comprenant un processeur et une unité radio-fréquence couplée de manière opérationnelle au processeur, le dispositif étant configuré pour la mise en œuvre d’un procédé selon l’un des modes de réalisation proposés dans la présente description.
[0025] Un autre aspect concerne un programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un procédé tel que proposé dans la présente description lors de l’exécution dudit programme par le processeur.
[0026] Un autre aspect concerne un ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur tel que proposé dans la présente description.
[0027] Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant un processeur couplé de manière opérationnelle à une mémoire et à une interface entrées/sorties de communication de données, conduire l’ordinateur à gérer un nœud de communication de données selon un procédé de gestion d’un nœud de communication de données selon l’un des modes de réalisation proposés dans la présente description.
Brève description des dessins
[0028] D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
Fig. 1 [0029] [Fig. 1] est un schéma illustrant un exemple de système pour la mise en œuvre d’un ou plusieurs modes de réalisation du procédé proposé ;
Fig. 2
[0030] [Fig. 2] est un schéma illustrant un exemple d’architecture d’un nœud routeur pour la mise en œuvre d’un ou plusieurs modes de réalisation du procédé proposé ;
Fig. 3a
[0031] [Fig. 3a] est un schéma illustrant un procédé proposé selon un ou plusieurs modes de réalisation ;
Fig. 3b
[0032] [Fig. 3b] est un schéma illustrant un procédé proposé selon un ou plusieurs modes de réalisation ;
Fig. 4
[0033] [Fig. 4] est un schéma illustrant un exemple de mesures du temps de propagation dans un routeur réflecteur de route dans un ou plusieurs modes de réalisation du procédé proposé;
Description des modes de réalisation
[0034] Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la présente description.
[0035] La présente description fait référence à des fonctions, moteurs, unités, modules, plateformes, et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, moteurs, modules, plateformes, unités et diagrammes décrits peut être mis en œuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué («firmware»), ou de «middleware»), microcode, ou toute combinaison de ces derniers. Dans le cas d’une mise en œuvre sous forme logicielle, les fonctions, moteurs, unités, modules et/ou illustrations de diagrammes peuvent être mis en œuvre par des instructions de programme d’ordinateur ou du code logiciel, qui peut être stocké ou transmis sur un support lisible par ordinateur, incluant un support non transitoire, ou un support chargé en mémoire d’un ordinateur générique, spécifique, ou de tout autre appareil ou dispositif programmable de traitement de données pour produire une machine, de telle sorte que les instructions de programme d’ordinateur ou le code logiciel exécuté(es) sur l’ordinateur ou l’appareil ou dispositif programmable de traitement de données, constituent des moyens de mise en œuvre de ces fonctions. [0036] Les modes de réalisation d’un support lisible par ordinateur incluent, de manière non exhaustive, des supports de stockage informatique et des supports de communication, y compris tout support facilitant le transfert d’un programme d’ordinateur d’un endroit vers un autre. Par «support(s) de stockage informatique», on entend tout support physique pouvant être accédé par ordinateur. Les exemples de support de stockage informatique incluent, de manière non limitative, les disques ou composants de mémoire flash ou tous autres dispositifs à mémoire flash (par exemple des clés USB, des clés de mémoire, des sticks mémoire, des disques-clés), des CD-ROM ou autres dispositifs de stockage optique de données, des DVD, des dispositifs de stockage de données à disque magnétique ou autres dispositifs de stockage magnétique de données, des composants de mémoire de données, des mémoires RAM, ROM, EEPROM, des cartes mémoires («smart cards»), des mémoires de type SSD («Solid State Drive»), et toute autre forme de support utilisable pour transporter ou stocker ou mémoriser des données ou structures de données qui peuvent être lues par un processeur d’ordinateur.
[0037] En outre, diverses formes de support lisible par ordinateur peuvent transmettre ou porter des instructions vers un ordinateur, telles qu’un routeur, une passerelle, un serveur, ou tout équipement de transmission de données, qu’il s’agisse de transmission filaire (par câble coaxial, fibre optique, fils téléphoniques, câble DSL, ou câble Ethernet), sans-fil (par infrarouge, radio, cellulaire, microondes), ou des équipements de transmission virtualisés (routeur virtuel, passerelle virtuelle, extrémité de tunnel virtuel, pare-feu virtuel). Les instructions peuvent, selon les modes de réalisation, comprendre du code de tout langage de programmation informatique ou élément de programme informatique, tel que, sans limitation, les langages assembleur, C, C++, Visual Basic, HyperText Markup Language (HTML), Extensible Markup Language (XML), HyperText Transfer Protocol (HTTP), Hypertext Preprocessor (PHP), SQL, MySQL, Java, JavaScript, JavaScript Object Notation (JSON), Python, et bash scripting.
[0038] De plus, les termes «notamment», «par exemple», «exemple», «typiquement» sont utilisés dans la présente description pour désigner des exemples ou illustrations de modes de réalisation non limitatifs, qui ne correspondent pas nécessairement à des modes de réalisation préférés ou avantageux par rapport à d’autres aspects ou modes de réalisation possibles.
[0039] Par «serveur» ou «plateforme», on entend dans la présente description tout point de service (virtualisé ou non) ou dispositif opérant des traitements de données, une ou plusieurs bases de données, et/ou des fonctions de communication de données. Par exemple, et de manière non limitative, le terme «serveur» ou le terme «plateforme» peut faire référence à un processeur physique couplé de manière opérationnelle avec des fonctions de communication, de base de données et de stockage de données associées, ou faire référence à un réseau, un groupe, un ensemble ou un complexe de processeurs et des équipements de stockage de données et de mise en réseau associés, ainsi qu’un système d’exploitation et un ou plusieurs système(s) de base de données et des logiciels applicatifs en support des services et fonctions fournies par le serveur. Un dispositif informatique peut être configuré pour envoyer et recevoir des signaux, par réseau(x) de transmission sans-fil et/ou filaire, ou peut être configuré pour des traitements et/ou du stockage de données ou de signaux, et peut donc fonctionner en tant que serveur. Ainsi, des équipements configurés pour opérer en tant que serveur peuvent inclure, à titre d’exemples non limitatifs, des serveurs dédiés montés sur rack, des ordinateurs de bureau, des ordinateurs portables, des passerelles de service (parfois appelées «box» ou «passerelle résidentielle»), des décodeurs multimédia (parfois appelés «set-top boxes»), des équipements intégrés combinant diverses fonctionnalités, telles que deux ou plus des fonctionnalités mentionnées ci-dessus. Les serveurs peuvent fortement varier dans leur configuration ou leurs capacités, mais un serveur inclura généralement une ou plusieurs unité(s) centrale(s) de traitement et une mémoire. Un serveur peut aussi inclure un ou plusieurs équipement(s) de mémoire de masse, une ou plusieurs alimentation(s) électrique(s), une ou plusieurs interface(s) réseau sans-fil et/ou filaire(s), une ou plusieurs interface(s) d’entrée/sortie, un ou plusieurs système(s) d’exploitation, tel(s) que Windows Server, Mac OS X, Unix, Linux, FreeBSD, or un équivalent.
[0040] Les termes «réseau» et «réseau de communication» tels qu’utilisés dans la présente description font référence à une ou plusieurs liaisons de données qui peuvent coupler ou connecter des équipements, éventuellement virtualisés, de manière à permettre le transport de données électroniques entre des systèmes informatiques et/ou des modules et/ou d’autres dispositifs ou équipements électroniques, tel qu’entre un serveur et un dispositif client ou d’autres types de dispositifs, y compris entre dispositifs sans fil couplés ou connectés par un réseau sans fil, par exemple. Un réseau peut aussi inclure une mémoire de masse pour stocker des données, tel qu’un NAS (en anglais «network attached storage», un SAN (en anglais «storage area network»), ou toute autre forme de support lisible par un ordinateur ou par une machine, par exemple. Un réseau peut comprendre, en tout ou partie, le réseau Internet, un ou plusieurs réseaux locaux (en anglais «local area networks», ou LANs), un ou plusieurs réseaux de type WAN (en anglais «wide area networks»), des connexions de type filaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. De manière similaire, des sous-réseaux peuvent utiliser différentes architectures ou être conformes ou compatibles avec différents protocoles, et inter-opérer avec des réseaux de plus grande taille. Différents types d’équipements peuvent être utilisés pour rendre interopérables différentes architectures ou différents protocoles. Par exemple, un routeur peut être utilisé pour fournir une liaison de communication ou une liaison de données entre deux LANs qui seraient autrement séparés et indépendants.
[0041] Les termes «couplé de manière opérationnelle», «couplé», «monté», «connecté» et leurs variantes et formes diverses utilisés dans la présente description font référence à des couplages, connexions, montages, qui peuvent être directs ou indirects, et comprennent notamment des connexions entre équipements électroniques ou entre des portions de tels équipements qui permettent des opérations et fonctionnements tels que décrits dans la présente description. De plus, les termes «connectés» et «couplés» ne sont pas limités à des connections ou des couplages physiques ou mécaniques. Par exemple, un couplage de manière opérationnelle peut inclure une ou plusieurs connexion(s) filaire(s) et/ou une ou plusieurs connexion(s) sans-fil entre deux équipements ou plus qui permettent des liaisons de communication simplex et/ou duplex entre les équipements ou des portions des équipements. Selon un autre exemple, un couplage opérationnel ou une connexion peut inclure un couplage par liaison filaire et/ou sans-fil pour permettre des communications de données entre un serveur du système proposé et un autre équipement du système.
[0042] Les termes «application» ou «programme applicatif» (AP) et leurs variantes («app», «webapp», etc.) tels qu’utilisés dans la présente description correspondent à tout outil qui fonctionne et est opéré au moyen d’un ordinateur, pour fournir ou exécuter une ou plusieurs fonction(s) ou tâche(s) pour un utilisateur ou un autre programme applicatif. Pour interagir avec un programme applicatif, et le contrôler, une interface utilisateur peut être fournie sur l’équipement sur lequel le programme applicatif est mis en œuvre. Par exemple, une interface graphique (en anglais, «graphical user interface» ou GUI) peut être générée et affichée sur un écran de l’équipement utilisateur, ou une interface utilisateur audio peut être restituée à l’utilisateur en utilisant un haut-parleur, un casque ou une sortie audio.
[0043] Par « protocole BGP », on entend un protocole de routage conforme à la spécification RFC 1771 puis RFC 4271 et/ou à toute autre spécification antérieure et/ou correspondante, telle que publiée par l’IETF ou par tout autre organisme ou groupe de normalisation, et/ou à leurs évolutions.
[0044] Bien que décrit dans le cadre de modes de réalisation utilisant le protocole BGP, l’homme du métier comprendra que les procédés, systèmes, logiciels et équipements proposés ne sont pas limités à un protocole de routage particulier, et que ceux-ci pourraient être mis en œuvre avec d’autres protocoles de routage, tels que, par exemple, le protocole IS-IS (RFC 1142) ou le protocole OSPF (RFC 2328 puis RFC 5340).
[0045] La figure 1 est un diagramme illustrant un ou plusieurs modes de réalisation dans lesquels un système (1) de communication de données comprenant une pluralité de N routeurs RTR1, RTR2, RTR3 (10a, 10b, 10c) interconnectés (N=3 dans l’exemple illustré), formant un réseau (2), configurés pour la mise en œuvre d’un protocole de routage, comme par exemple le protocole BGP. Les trois routeurs RTR1 (10a), RTR2 (10b) et RTR3 (10c) illustrés sur la figure peuvent donc être des routeurs activant le protocole BGP et donc aptes à échanger des messages du protocole BGP et à mettre en œuvre les fonctionnalités définies pour le protocole BGP. Les routeurs RTR1 (10a), RTR2 (10b) et RTR3 (10c) peuvent être connectés à des équipements (l ia, 11b, 11c, l ld, l ie, l lf, 11g) qui n’activent pas le protocole BGP, comme par exemple des set-top boxes, des boxes, des switches, des ordinateurs, des équipements utilisateurs (tablettes, etc.). [0046] En particulier, chacun des routeurs du réseau (1) peut être configuré pour fonctionner en mode « annonceur BGP » (en anglais, « BGP speaker ») tel que défini par la RFC 1771 puis la RFC 4271. Dans ce mode, lorsqu’un routeur (par exemple le routeur RTR1 ( 10a), sur la figure 1 ) reçoit une route externe pour l’acheminement de données et est sélectionné comme meilleur chemin pour ces données, il doit annoncer cette information aux autres routeurs du réseau (par exemple les routeurs RTR2 et RTR3 du réseau (1) sur la figure 1).
[0047] Pour ce faire, dans les cas où le réseau (1) est configuré selon une architecture de réseau maillé, le routeur annonceur RTR1 doit annoncer son information à chacun des autres routeurs, RTR2 et RTR3 dans l’exemple de la figure 1, ce qui amène à utiliser des ressources de communication entre chaque paire de routeurs RTR1-RTR2 et RTR1-RTR3.
[0048] Afin d’éviter un volume important de trafic de signalisation BGP dans le cas où le réseau (1) comprend un grand nombre de routeurs, le réseau peut utiliser une ou plusieurs des fonctions de réflexion de route (en anglais, « route reflection ») décrites dans le document RFC 4456 édité par l’IETF, intitulé « BGP Route Reflection - An Alternative to Full Mesh IBGP ».
[0049] La fonction de réflecteur de route permet typiquement d’éviter l’interconnexion d’un grand nombre de routeurs selon une architecture de réseau maillé (en anglais, « mesh network ») dans laquelle les routeurs sont par exemple interconnectés deux à deux. Le nœud RR permet ainsi d’éviter les problèmes d’échelle qui se présentent lorsqu’un grand nombre de routeurs doivent tous recevoir une information de routage externe. La réflexion de route permet ainsi d’éviter la mise en œuvre d’une architecture de type réseau maillé, par la mise en œuvre au sein d’un des routeurs du réseau (1) d’une fonction de réflecteur de route (en anglais, « Route reflector », ou « RR ») telle que définie dans la RFC 4456.
[0050] L’architecture du réseau peut alors prévoir que l’un des nœuds routeur du réseau fonctionnera en mode nœud RR, auquel cas le nœud RR sera configuré pour échanger des données avec chacun des autres nœuds routeur du réseau. Dans la pratique, le nombre de routeurs connectés à un nœud RR pourra atteindre plusieurs centaines, ce qui montre l’avantage qu’il peut y avoir à utiliser un nœud RR.
[0051] Dans un ou plusieurs modes de réalisation, le nœud RR peut être configuré pour mettre en œuvre une ou plusieurs des fonctions spécifiées dans le document RFC 4456. Ainsi, comme illustré sur la figure 1, un réseau comprenant une pluralité de routeurs (RTR1, 10a ; RTR2, 10b, RTR3, 10c) peut utiliser un nœud RR (RTR2, 10b) afin de mettre en œuvre la distribution des informations de routage externes à tous les routeurs du réseau par le biais du nœud RR (RTR2, 10b). Lorsqu’un routeur a une information de routage à partager avec les autres routeurs du réseau, il peut envoyer cette information au nœud RR qui se charge de la redistribution aux autres routeurs. [0052] Le nœud routeur RR RTR2 (10b) peut ainsi fournir une interface entre tous les routeurs RTR1 (10a), RTR3 (10c) du réseau (2), ces routeurs n’ayant qu’à établir une session de communication de données avec le nœud routeur RR RTR2 (10b). Dans l’exemple de la figure 1, chaque routeur RTR1 (10a), RTR3 (10c) autre que le nœud routeur RR RTR2 (10b) peut avoir établi au préalable une session de communication de données avec le nœud routeur RR RTR2 ( 10b) pour l’échange de messages du protocole de routage avec ce nœud routeur RR RTR2 (10b).
[0053] En fonction du mode de réalisation, la fonction RR pourra être mise en oeuvre, en tout ou partie, au sein d’un des nœuds routeurs du réseau, et/ou en tout ou partie au sein d’un autre type de nœud du réseau.
[0054] Par exemple, dans un ou plusieurs modes de réalisation, le réseau (2) formé par les nœuds routeurs pourra être de tout type de réseau de communication de données, comme par exemple un réseau de paquets de données (en anglais, « Packet Data Network », ou PDN), et comprendre un ou plusieurs réseaux de transmission de données de type réseau IP (de l’anglais « Internet Protocol »), et utiliser des liens de communication basés sur les protocoles TCP, IP, et/ou tous types de protocole utilisables pour la communication de données dans un réseau de communication de données. En outre, en fonction du mode de réalisation, le réseau (2) pourra utiliser un ou plusieurs protocoles de routage, tels que par exemple le protocole BGP, le protocole ISIS, et/ou le protocole OSPF.
[0055] En référence à la figure 2, dans un ou plusieurs modes de réalisation, chaque nœud routeur (10) du réseau (par exemple chacun des nœuds routeur RTR1 (10a), RTR2 (10b), RTR3 (10c) de la figure 1) pourra comprendre une unité de communication de données (20), un contrôleur (21), une unité de routage (22), et une unité de mesure de temps de propagation (23). Selon le mode de réalisation, l’unité de communication de données (20), l’unité de routage (22), et l’unité de mesure de temps de propagation (23) pourront être couplées de manière opérationnelle au contrôleur (21) par un bus de communication (24), ou par tout lien de communication, comprenant éventuellement un ou plusieurs connecteurs matériels. Dans l’architecture du nœud routeur (10) illustré sur la figure 2, l’ensemble des unité de communication de données (20), contrôleur (21), unité de routage (22), unité de mesure de temps de propagation (23), unité fonctionnelle (24) et bus de communication (24) forme un nœud routeur selon un ou plusieurs modes de réalisation, qui peut par ailleurs inclure d’autres composants, unités, fonctions, non représentés sur la figure.
[0056] Le contrôleur (21) peut comprendre un ou plusieurs processeurs, comme microprocesseur, un microcontrolleur ou un autre processeur matériel, une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire cache, une mémoire flash, etc.), et être apte à être configuré pour piloter l’unité de communication de données (20), l’unité de routage (22), l’unité de mesure de temps de propagation (23), afin de commander l’utilisation du nœud routeur ( 10) selon un ou plusieurs modes de réalisation du procédé proposé, par exemple en exécutant un programme d’ordinateur comprenant des portions de code pour la mise en œuvre d’un procédé de mesure du temps de propagation d’une information relative au routage de données tel que proposé dans la présente description. En fonction du mode de réalisation, une mémoire associée du contrôleur (21), externe ou interne au contrôleur (21), contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur (21), amènent ce contrôleur (21) à effectuer ou contrôler les parties unité de communication de données (20), unité de routage (22), et/ou unité de mesure de temps de propagation (23) des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur (21) peut être un composant implémentant un processeur ou une unité de calcul pour la mesure du temps de propagation d’une information relative au routage de données selon le procédé proposé et le contrôle de l’unité de mesure de temps de propagation (23) du dispositif (10), comme par exemple un microcontrôleur.
[0057] L’unité de mesure de temps de propagation (23) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’un ou plusieurs logiciels, ou d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, configurés pour la mise en œuvre de modes de réalisation du procédé de gestion décrit dans la présente description. En particulier, le nœud routeur ( 10) peut être configuré par l’intermédiaire de l’unité de mesure de temps de propagation (23) pour fonctionner selon une pluralité de modes opératoires, parmi lesquels se trouvent un mode opératoire dit « nœud générateur » et un mode opératoire dit « nœud récepteur », et pour fonctionner en mode nœud générateur et/ou en mode nœud récepteur selon un ou plusieurs modes de réalisation décrits dans la présente description.
[0058] La partie logicielle de l’unité de mesure de temps de propagation (23) peut constituer ou faire partie d’un logiciel de pilotage du nœud routeur (10). Dans la suite, on désignera par « logiciel de pilotage » (en anglais, « driver ») un ensemble d’un ou plusieurs logiciels configurés pour la mise en œuvre d’un procédé de mesure du temps de propagation d’une information relative au routage de données tel que proposé dans la présente description. En fonction de l’architecture du nœud routeur, le logiciel de pilotage est configuré pour être exécutable sur un processeur du nœud routeur, et/ou sur un processeur d’un équipement informatique auquel une partie du nœud routeur est connectée.
[0059] L’unité de communication de données (20) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, et comprendre un ou plusieurs matériels de communication filaire, radiofréquence et/ou optique, et un logiciel de pilotage d’unité de communication, par exemple exécutable par le contrôleur (21) ou, dans une autre architecture du nœud de communication, exécutable par un processeur de l’unité de communication de données (20), et chargé dans une mémoire accessible par un processeur configuré pour exécuter le logiciel de pilotage d’unité de communication. Dans un ou plusieurs modes de réalisation, l’unité de communication de données (20) peut comprendre une interface de communication de données. [0060] L’unité de routage (22) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, et comprendre une ou plusieurs unités de gestion de protocole de routage, par exemple exécutable par le contrôleur (21) ou, dans une autre architecture du nœud routeur, exécutable par un processeur de l’unité de routage (22), et chargé dans une mémoire accessible par un processeur configuré pour exécuter le logiciel de pilotage d’unité de routage. Par exemple, l’unité de routage (22) pourra être configurée pour mettre en œuvre une ou plusieurs des fonctionnalités d’un protocole de routage, tel que le protocole BGP, le protocole ISIS, et/ou le protocole OSPF.
[0061] Le dispositif nœud routeur (10) peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). Les SOC (System On Chip) ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d’un système électronique dans une puce unique. Un ASIC (Application-specific Integrated Circuit) est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l’utilisateur. Les circuits logiques programmables de type FPGA (Field- Programmable Gâte Array) sont des circuits électroniques reconfigurables par l’utilisateur.
[0062] Le dispositif nœud routeur (10) peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).
[0063] En fonction du mode de réalisation, différentes architectures du dispositif nœud routeur ( 10) peuvent être adoptées, tant pour la partie matérielle du dispositif, que pour la partie logicielle du dispositif, le cas échéant.
[0064] L’homme du métier comprendra que le procédé proposé n’est pas limité à une architecture particulière du nœud routeur (10), de l’unité de communication de données (20), du contrôleur (21), de l’unité de routage (22), de l’unité de mesure de temps de propagation (23) et du bus de communication (25), ou du couplage entre ces éléments illustrant à titre d’exemple un mode de réalisation sur la figure 2.
[0065] On décrit ci-après des procédés de mesure du temps de propagation d’une information de routage de données dans un système de communication de données tel que celui illustré sur les figures 1 et 2, dans un ou plusieurs modes de réalisation.
[0066] En référence aux figures 3a et 3b, dans un ou plusieurs modes de réalisation, l’un au moins des nœuds de communication (RTR2, 10b) du système (1) peut être configuré pour fonctionner en mode routeur RR, et un autre nœud routeur du système (1) (RTR1, 10a) peut être configuré pour générer (40) des données d’horodatage d’émission d’une information relative au routage de données, et insérer (41) les données d’horodatage d’émission dans un champ d’un message du protocole de routage BGP, le champ étant destiné à recevoir des données relatives au routage de données.
[0067] Le nœud routeur RTR1 ( 10a) peut alors envoyer (42) le message au nœud routeur RR RTR2 pour annoncer aux autres routeurs du réseau (2) l’information relative au routage de données portée par le message. Par exemple, dans le cas d’une utilisation du protocole de routage BGP, le message de protocole utilisé pour la mise en œuvre du procédé proposé peut être, en fonction du mode de réalisation, du type « UPDATE » ou du type « WITHDRAWN ». Le nœud routeur RTR1 envoie ainsi des données d’horodatage sous forme d’une information de routage dans le cadre de l’annonce de l’information de routage aux autres routeurs du réseau auxquels l’information de routage doit être annoncée selon le protocole de routage utilisé.
[0068] Sur réception du message en provenance du nœud routeur RTR1 (10a), le nœud routeur RR RTR2 (10b) effectue les traitements nécessaires pour transmettre l’information de routage contenue dans le message aux autres nœuds routeurs du réseau (2), et en particulier le nœud routeur RTR3 (10c).
[0069] Dans un ou plusieurs modes de réalisation, le nœud RTR3 (10c) peut être configuré pour, sur réception (50) d’un message du protocole de routage en provenance d’un autre nœud routeur, par exemple le nœud routeur RR RTR2 (10b) dans l’exemple de réseau illustré sur la figure 1, extraire (51) d’un champ du message reçu des données d’horodatage, le champ étant destiné à recevoir des données relatives au routage de données. En référence à la figure 1, les données d’horodatage peuvent correspondre à celles insérées par le nœud routeur RTR1 (10a) dans un champ du message de protocole de routage envoyé au nœud routeur RR RTR2 (10b). Le nœud routeur RTR3 (10c) pourra donc être configuré comme nœud récepteur pour effectuer des mesures de temps de traitement et de propagation d’un message du protocole de routage émis par un autre nœud routeur, configuré pour fonctionner comme nœud émetteur de messages de test, par un routeur ou un réseau de routeurs objet du test. En particulier, le nœud routeur récepteur pourra être configuré (par exemple préconfiguré) pour identifier, parmi les messages reçus ou parmi les différents types de messages reçus, ceux utilisés par le nœud routeur émetteur pour y insérer une information d’horodatage d’émission. De la même manière, le nœud routeur émetteur pourra être configuré (par exemple préconfiguré) pour insérer une information d’horodatage dans un message de protocole prédéfini ou d’un type prédéfini (par exemple un ou plusieurs messages de type UPDATE et/ou WITHDRAW pour le protocole de routage BGP), selon une configuration de test correspondante à celle utilisée pour configurer le nœud routeur récepteur.
[0070] Dans un ou plusieurs modes de réalisation, le nœud RTR3 (10c) peut en outre être configuré pour extraire du message reçu une information relative à un routeur à l'origine de ladite information relative au routage de données, soit dans l’exemple de la figure 1 extraire du message reçu une information permettant d’identifier le nœud routeur RTR1 (10a) à l’origine du message reçu (et donc des données d’horodatage qu’il contient).
[0071] Dans un ou plusieurs modes de réalisation, le nœud routeur RTR3 (10c) peut en outre être configuré pour générer (52) des données d’horodatage courant, puis déterminer (53) une estimation du temps de propagation de l’information de routage entre le routeur à l’origine du message et le routeur de destination du message (c’est-à-dire le nœud routeur RTR3 (10c) lui-même), sur la base d’une différence entre les données d’horodatage extraites du message et les données d’horodatage courant.
[0072] En référence à la figure 1, le nœud routeur de destination du message, RTR3 (10c) peut être configuré pour, sur réception du message en provenance du nœud routeur RTR1 (10a) via le nœud routeur RR RTR2 (10b), estimer un temps de propagation du message, ce temps de propagation comprenant la propagation du message depuis le routeur d’origine du message, RTR1 (10a) jusqu’au routeur de destination, RTR3 (10c) et le traitement du message par le nœud intermédiaire RTR2 (10b). Le nœud routeur de destination RTR3 (10c) peut ainsi avantageusement mesurer le temps cumulé nécessaire au nœud routeur RR RTR2 (10b), pour traiter le message, une fois reçu en provenance du nœud routeur d’origine RTR1 (10a) et pour le retransmettre à l’ensemble des autres nœuds routeurs du réseau (2).
[0073] Dans le cadre d’une mise en œuvre utilisant le protocole BGP, les messages BGP de type UPDATE ou de type WITHDRAWN pourront être utilisés dans un ou plusieurs modes de réalisation.
[0074] Dans un ou plusieurs modes de réalisation, les données d’horodatage pourront être de format nombre flotant sur 32 bits, avec la partie entière représentant le nombre de secondes écoulées depuis le 01/01/1970 et la partie décimale représentant le nombre de microsecondes à ajouter au nombre de secondes.
[0075] Le protocole BGP définit des messages BGP de type UPDATE pour entre autres effectuer l’annonce et/ou le retrait d’une information relative au routage, telle qu’une information d’accessibilité, comme par exemple un préfixe. Les messages BGP de type UPDATE comprennent quatre parties distinctes, dont un en-tête (en anglais, « header »), une partie « attribut de chemin » (en anglais, « Paths Attributes »), une partie « retrait » (en anglais, « Withdrawn ») et une partie « NLRI » (de l’anglais « Network Layer Reachability Information ») La partie « attribut de chemin » peut être utilisée pour indiquer la liste des propriétés associées à l’information relative au routage (par exemple au préfixe). La partie « retrait » peut être utilisée pour indiquer une information d’accessibilité, comme un ensemble de préfixes à retirer. La partie « NLRI » peut être utilisée pour indiquer des préfixes à créer/modifier et auxquels on associe le ou les attributs indiqués dans la partie « atribut ».
[0076] Différents types d’attribut peuvent être renseignés dans la partie « attribut », parmi lesquels le type d’atribut obligatoire « ORIGIN » pour définir l’origine de l’information de routage, le type d’attribut obligatoire « AS-PATH » pour définir une suite de segments de routes de systèmes autonomes, le type d’attribut obligatoire « NEXT HOP » pour définir l’adresse IP d’un routeur de frontière, le type d’attribut optionnel « MULTI EXIT DISC » pour définir différents points de sortie d’un système autonome, le type d’attribut discrétionnaire « LOCAL PREF » pour informer les routeurs d’un système autonome du degré de préférence d’un routeur annonceur pour une route annoncée, le type d’attribut discrétionnaire « ATOMIC AGGREGATE » ou le type d’attribut optionnel « AGGREGATOR ».
[0077] On pourra se reporter à la spécification RFC 4271 , par exemple dans l’édition de mars 1995, pour une description détaillée du message BGP UPDATE et des champs de ce message.
[0078] Dans un ou plusieurs modes de réalisation, une information de type horodatage peut être insérée, sous forme de données d’horodatage, dans un message de protocole BGP, par exemple dans un message de type UPDATE.
[0079] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message BGP UPDATE destiné à recevoir des données représentant une information relative au routage de données, comme par exemple des données de préfixe (par exemple préfixe d’adresse IP ou préfixe VPN).
[0080] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « attribut ». Par exemple, les données d’horodatage peuvent être insérées en tant qu’attribut avec un type d’attribut déjà existant, comme par exemple le type optionnel « LOCAL PREF ». Ainsi, on peut utiliser un type d’attribut ayant un format compatible avec celui des données d’horodatage à transmettre pour transmettre ces données dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans un message UPDATE comme attribut de type « LOCAL PREF ».
[0081] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « retrait ». Par exemple, les données d’horodatage peuvent être insérées en tant que préfixe Internet ou VPN. Ainsi, le champ « retrait » étant utilisé pour indiquer une liste de préfixes d’adresse IP pour les routes qui sont retirées du service, on peut transmettre des données d’horodatage ayant un format compatible avec celui d’un ou de plusieurs préfixes d’adresse IP en insérant ces données comme étant un ou plusieurs préfixes d’adresse IP dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans le champ « retrait » d’un message UPDATE comme préfixe(s) d’adresse IP.
[0082] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « NLRI ». Par exemple, les données d’horodatage peuvent être insérées en tant que préfixe Internet ou VPN. Ainsi, le champ « NLRI » étant utilisé pour indiquer une liste de préfixes d’adresse IP, on peut transmettre des données d’horodatage ayant un format compatible avec celui d’un ou de plusieurs préfixes d’adresse IP en insérant ces données comme étant un ou plusieurs préfixes d’adresse IP dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans le champ « NLRI » d’un message UPDATE comme préfixe(s) d’adresse IP.
[0083] Ainsi, dans un ou plusieurs modes de réalisation, un routeur BGP dit routeur « générateur » ou routeur « d’origine », génère un message BGP de type UPDATE, et insère des données d’horodatage d’émission dans le message BGP UPDATE en tant qu’ attribut dans la partie « attribut », en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « retrait », et/ou en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « NLRI ». Le routeur BGP générateur envoie ensuite le message BGP UPDATE au routeur (par exemple un routeur RR) ou au réseau dont on souhaite mesurer le temps de propagation (comprenant le temps de traitement).
[0084] Ledit routeur ou réseau effectue les traitements nécessaires pour prendre en compte des informations contenues dans le message BGP UPDATE envoyé par le routeur « générateur », et propager ce message à ses voisins après avoir effectué les traitements requis.
[0085] Un des routeurs recevant le message en provenance dudit routeur ou réseau, dit routeur « récepteur » ou routeur « de destination », est configuré pour extraire du message reçu les données d’horodatage. Par exemple, en fonction du mode de réalisation, si le routeur générateur est configuré pour insérer des données d’horodatage d’émission dans un message BGP UPDATE en tant qu’ attribut dans la partie « attribut », en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « retrait », et/ou en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « NLRI », le routeur récepteur sera, de manière correspondante, configuré pour extraire ces données d’horodatage d’un message BGP UPDATE reçu, comme attribut de la partie « attribut », comme préfixe d’adresse IP ou préfixe VPN de la partie « retrait », et/ou comme préfixe d’adresse IP ou préfixe VPN de la partie « NLRI », respectivement.
[0086] Le routeur récepteur peut ensuite comparer les données d’horodatage reçues avec son propre horodatage, pour en déduire le temps de propagation (y compris le temps de traitement) nécessaire audit routeur ou réseau.
[0087] La figure 4 illustre un exemple de mesures du temps de propagation dans un routeur RR dans un ou plusieurs modes de réalisation.
[0088] Ces mesures sont les résultats de tests effectués en exécutant des routines de test sur un routeur générateur de test BGP préconfiguré avec 5 millions de routes BGP à travers 330 sessions de communication de données avec un routeur RR.
[0089] Dans un premier test, le routeur générateur de test exécute une routine en boucle infinie, chaque instance de boucle comprenant (1) l’exécution de dix instances d’une boucle de génération et d’émission d’un message BGP UPDATE contenant des données d’horodatage dans le champ « Route Distinguisher » (qui un élément d’une route VPN-IPv4 ou VPN-IPv6)du message BGP UPDATE, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, (2) un temps d’attente prédéterminé (par exemple 10 s), (3) l’exécution de dix autres instances de boucle de génération et d’émission d’un message BGP UPDATE contenant des données d’horodatage dans le champ « Route Distinguisher » (qui un élément d’une route VPN-IPv4 ou VPN-IPv6) du message BGP UPDATE, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, et (4) un temps d’attente prédéterminé (par exemple 10 s).
[0090] Le routeur générateur de test BGP envoie donc quasiment en permanence à un routeur RR dont on cherche à mesurer le temps de traitement et propagation 10 messages UPDATE qui contiennent des modifications de route et des données d’horodatage. Le routeur RR traite chacun de ces messages, et les annonce à un routeur récepteur de test BGP. Le routeur récepteur de test BGP est configuré pour recevoir les messages BGP UPDATE en provenance du routeur RR, extraire de chaque message BGP UPDATE reçu des données d’horodatage depuis le champ « Route Distinguisher » du message, et déterminer une mesure du temps de traitement et propagation au routeur RR à partir de son propre horodatage et des données d’horodatage reçues.
[0091] Les résultats de ce premier test correspondent au nuage de points inférieur de la figure 4, avec une droite de tendance d’équation : y = 0.1041 — 4544.5.
[0092] Dans un deuxième test, le routeur générateur de test exécute une routine en boucle infinie, chaque instance de boucle comprenant (1) l’exécution de dix instances d’une boucle de génération et d’émission d’un message BGP WITHDRAW contenant des données d’horodatage dans le champ « Route Distinguisher » du message BGP WITHDRAW, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, (2) un temps d’attente prédéterminé (par exemple 10 s), (3) l’exécution de dix autres instances de boucle de génération et d’émission d’un message BGP WITHDRAW contenant des données d’horodatage dans le champ « Route Distinguisher » du message BGP WITHDRAW, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, et (4) un temps d’attente prédéterminé (par exemple 10 s).
[0093] Le routeur générateur de test BGP envoie donc quasiment en permanence à un routeur RR dont on cherche à mesurer le temps de traitement et propagation 10 messages WITHDRAW qui contiennent des modifications de route et des données d’horodatage. Le routeur RR traite chacun de ces messages, et les annonce à un routeur récepteur de test BGP. Le routeur récepteur de test BGP est configuré pour recevoir les messages BGP WITHDRAW en provenance du routeur RR, extraire de chaque message BGP WITHDRAW reçu des données d’horodatage depuis le champ « Route Distinguisher » du message, et déterminer une mesure du temps de traitement et propagation nécessaire au routeur RR pour le retrait d’une route à partir de son propre horodatage et des données d’horodatage reçues. [0094] Les résultats de ce premier test correspondent au nuage de points inférieur de la figure 4, avec une droite de tendance d’équation y = 0.1213 — 5292.9.
[0095] Le procédé proposé fournit une solution de mesure de temps de propagation dans un routeur ou dans un réseau utilisant un protocole de routage qui est avantageusement simple de mise en œuvre, notamment en ce qu’elle ne nécessite pas de développements supplémentaires sur le protocole de routage. Le procédé proposé peut ainsi être mise en œuvre par logiciel, de manière indépendante, c’est- à-dire sans dépendre d’une mise en œuvre particulière du protocole de routage ou d’un équipement propriétaire sur lequel il est mis en œuvre.
[0096] Le procédé proposé implique en outre avantageusement un faible coût de calculs, de sorte qu’il peut être mis en œuvre en parallèle à d’autres tests pour voir l’impact de ces autres tests sur le temps de propagation mesuré par le procédé proposé.
Application industrielle
[0097] En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.
[0098] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé de pilotage proposé et le dispositif pour la mise en œuvre d’un mode de réalisation du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous-combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.

Claims

Revendications
[Revendication 1] Procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur dit nœud générateur : générer des données d’horodatage d’émission de l’information relative au routage de données ; insérer les données d’horodatage d’émission dans un champ d’un message du protocole de routage porteur de l’information relative au routage de données, le champ étant destiné à recevoir des données relatives au routage de données ; et envoyer le message à un autre nœud routeur dit nœud récepteur.
[Revendication 2] Procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des noeuds du réseau de communication de données, le procédé comprenant, à un nœud routeur, dit nœud récepteur : recevoir un message du protocole de routage porteur de l’information relative au routage de données en provenance d’un autre nœud routeur ; extraire d’un champ du message reçu des données d’horodatage, le champ étant destiné à recevoir des données relatives au routage de données; générer des données d’horodatage courant ; et déterminer une estimation du temps de propagation de l’information relative au routage de données entre le noeud générateur et le noeud récepteur, sur la base des données d’horodatage du message et des données d’horodatage courant.
[Revendication 3] Procédé selon la revendication 2, comprenant en outre : extraire du message reçu une information relative à un routeur à l'origine de l’information relative au routage de données, dit noeud générateur.
[Revendication 4] Procédé selon l’une quelconque des revendications précédentes, dans lequel les données d’horodatage sont insérées dans le message en tant que préfixe d’adresse Internet Protocol, IP, ou préfixe de réseau privé virtuel, VPN.
[Revendication 5] Procédé selon l’une quelconque des revendications précédentes, dans lequel le protocole de routage est le protocole « Border Gateway Protocol », BGP.
[Revendication 6] Procédé selon la revendication 5, dans lequel le message du protocole de routage est du type BGP -UPDATE.
[Revendication 7] Procédé selon la revendication 6, dans lequel les données d’horodatage d’émission sont insérées dans la partie « attribut », la partie « withdrawn » ou la partie « NLRI » du message BGP -UPDATE.
[Revendication 8] Procédé selon la revendication 7, dans lequel les données d’horodatage d’émission sont insérées dans la partie « attribut » en utilisant un attribut prédéfini, la partie « withdrawn » en tant que préfixe Internet ou VPN, ou la partie « NLRI » du message BGP-UPDATE en tant que préfixe Internet ou VPN.
[Revendication 9] Procédé selon l’une quelconque des revendications 1 à 4, dans lequel le protocole de routage est le protocole de routage interne « Intermediate System to Intermediate System », IS-IS, ou le protocole de routage interne IP « Open Shortest Path First », OSPF.
[Revendication 10] Nœud de réseau de communication de données comprenant un processeur et une interface de communication couplée de manière opérationnelle au processeur, le nœud de réseau étant configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 10.
[Revendication 11] Programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 10 lors de l’exécution dudit programme par le processeur.
[Revendication 12] Ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur selon la revendication 12.
[Revendication 13] Support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d’interface entrées/sorties, conduire l’ordinateur à mettre en œuvre le procédé de l’une quelconque des revendications 1 à 10.
EP21707319.6A 2020-01-06 2021-01-04 Routage de donnees dans un systeme de communication Pending EP4088429A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2000068A FR3106027A1 (fr) 2020-01-06 2020-01-06 Procédé de gestion du routage de données dans un système de communication et dispositifs pour la mise en œuvre du procédé
PCT/FR2021/050001 WO2021140289A1 (fr) 2020-01-06 2021-01-04 Routage de donnees dans un systeme de communication

Publications (1)

Publication Number Publication Date
EP4088429A1 true EP4088429A1 (fr) 2022-11-16

Family

ID=72266340

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21707319.6A Pending EP4088429A1 (fr) 2020-01-06 2021-01-04 Routage de donnees dans un systeme de communication

Country Status (4)

Country Link
US (1) US20230031496A1 (fr)
EP (1) EP4088429A1 (fr)
FR (1) FR3106027A1 (fr)
WO (1) WO2021140289A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11909763B2 (en) * 2021-04-07 2024-02-20 Cisco Technology, Inc. BGP blackhole and hijack mitigation

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544325A (en) * 1994-03-21 1996-08-06 International Business Machines Corporation System and method for generating messages for use in transaction networks
CA2361255C (fr) * 2000-11-06 2006-01-24 Matsushita Electric Industrial Co., Ltd. Systeme, appareil et programme de compression d'en-tete
US9137033B2 (en) * 2003-03-18 2015-09-15 Dynamic Network Services, Inc. Methods and systems for monitoring network routing
US7430176B2 (en) * 2005-02-15 2008-09-30 Cisco Technology, Inc. Adaptive timing of update messages transmitted by routers employing the border gateway protocol
US8458539B2 (en) * 2010-06-24 2013-06-04 Intel Corporation G-ODLAT on-die logic analyzer trigger with parallel vector finite state machine
US8908517B2 (en) * 2011-03-10 2014-12-09 Cisco Technology, Inc. Traffic distribution across a plurality of attachment circuits of a multihome site with a computer network using hashing algorithm
US8923515B2 (en) * 2011-05-12 2014-12-30 Futurewei Technologies, Inc. System and method for mobility management in a communications system
US9106510B2 (en) * 2012-04-09 2015-08-11 Cisco Technology, Inc. Distributed demand matrix computations
CN104247377B (zh) * 2012-07-09 2018-07-27 松下知识产权经营株式会社 通信装置、通信方法、程序
CN102801821A (zh) * 2012-08-10 2012-11-28 中国联合网络通信集团有限公司 地址生成和解析方法、用户设备和网络节点
US20140297821A1 (en) * 2013-03-27 2014-10-02 Alcatel-Lucent Usa Inc. System and method providing learning correlation of event data
US20140337950A1 (en) * 2013-05-07 2014-11-13 Futurewei Technologies, Inc. Method and Apparatus for Secure Communications in a Wireless Network
ES2757505T3 (es) * 2013-07-12 2020-04-29 Huawei Tech Co Ltd Método para implementar túnel de GRE, dispositivo de acceso y puerta de agregación
US9391867B2 (en) * 2013-08-14 2016-07-12 Broadcom Corporation Method and implementation for network instrumentation and traffic disposition with timestamps
US9787559B1 (en) * 2014-03-28 2017-10-10 Juniper Networks, Inc. End-to-end monitoring of overlay networks providing virtualized network services
US10298344B1 (en) * 2015-03-06 2019-05-21 Marvell International Ltd. Systems and methods for indicating when frames egress a PHY module of a network device
US9942046B2 (en) * 2015-05-06 2018-04-10 21, Inc. Digital currency mining circuitry with adaptable difficulty compare capabilities
CN114422400B (zh) * 2015-09-04 2023-09-05 动态网络服务股份有限公司 使用实时用户监控数据进行实时流量引导的方法和装置
US10541900B2 (en) * 2016-02-01 2020-01-21 Arista Networks, Inc. Hierarchical time stamping
WO2018175246A1 (fr) * 2017-03-19 2018-09-27 TokenID, Inc. Appareil et procédé d'autorisation de paiement et segmentation en unités sur la base d'une authentification
CN110555020B (zh) * 2018-03-26 2023-04-11 阿里巴巴集团控股有限公司 一种映射关系建立、数据查询方法、装置及设备
US10917340B2 (en) * 2018-09-11 2021-02-09 Cisco Technology, Inc. In-situ passive performance measurement in a network environment
US11057857B2 (en) * 2018-09-28 2021-07-06 Intel Corporation Technologies for managing internal time synchronization
US10893022B1 (en) * 2018-12-20 2021-01-12 Equinix, Inc. Routing protocol security using a distributed ledger

Also Published As

Publication number Publication date
US20230031496A1 (en) 2023-02-02
FR3106027A1 (fr) 2021-07-09
WO2021140289A1 (fr) 2021-07-15

Similar Documents

Publication Publication Date Title
US12255817B2 (en) Executing workloads across multiple cloud service providers
FR3096533A1 (fr) Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé
Mankowski et al. TLS→ Post-Quantum TLS: Inspecting the TLS landscape for PQC adoption on Android
FR3074626A1 (fr) Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
EP4088429A1 (fr) Routage de donnees dans un systeme de communication
EP4457993A1 (fr) Communication d'architecture de service 5g (sba) sur la base d'un apprentissage automatique
EP2847939A1 (fr) Systeme de transmission de donnees
WO2020221779A1 (fr) Procedes et dispositifs de mesure de reputation dans un reseau de communication
US9172607B2 (en) Transmitting of configuration items within a network
CN108011777A (zh) 用于更新边界网络设备的路由信息的方法和装置
EP4367831A1 (fr) Procede d'etablissement authentifie d'une connexion entre un equipement raccorde a au moins un reseau de communication et un serveur d'un fournisseur de services et dispositifs correspondants
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
FR3003115A1 (fr) Procede d'allocation de ressources pour la mise en oeuvre de reseaux virtuels dans un reseau de telecommunication
US12294499B1 (en) Pluggable transceiver to facilitate network traffic analysis
US12542779B1 (en) Secure and dynamic peer-based network connection configuration, routing, and control
WO2019243706A1 (fr) Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication
FR3145253A1 (fr) Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
FR3164588A1 (fr) Dispositif et procédé de génération de signatures agrégées vérifiable localement pour la génération d’attestations dans une plateforme d’architecture VNF-FG
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
EP4203419A1 (fr) Mise en communication automatique de sondes reseau
WO2023078993A1 (fr) Procédé de gestion d'une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d'une valeur d'un paramètre de performance intermédiaire
WO2023067267A1 (fr) Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau
FR3129050A1 (fr) Procédé de vérification de la fiabilité d’une première valeur d’un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d’une valeur d’un paramètre de performance intermédiaire déterminée par le nœud intermédiaire
CN120602320A (zh) 数据处理方法、装置、设备、存储介质及程序产品
FR2878671A1 (fr) Procede d'authentification de la decouverte de voisinage de l'environnement reseau ip d'un terminal candidat a un acces reseau

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220805

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250321