EP2997717A1 - Procede et dispositif de selection d'interface de communication - Google Patents

Procede et dispositif de selection d'interface de communication

Info

Publication number
EP2997717A1
EP2997717A1 EP14726086.3A EP14726086A EP2997717A1 EP 2997717 A1 EP2997717 A1 EP 2997717A1 EP 14726086 A EP14726086 A EP 14726086A EP 2997717 A1 EP2997717 A1 EP 2997717A1
Authority
EP
European Patent Office
Prior art keywords
interface
cost
link
host
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.)
Withdrawn
Application number
EP14726086.3A
Other languages
German (de)
English (en)
Inventor
Arnaud KAISER
Alexandru Petrescu
Christophe Janneteau
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.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Publication of EP2997717A1 publication Critical patent/EP2997717A1/fr
Withdrawn 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
    • 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/0876—Network utilisation, e.g. volume of load or congestion level
    • 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/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses

Definitions

  • the invention relates to the field of network communications and in particular relates to a method and a device for selecting a communication interface for the routing of data.
  • State of the art relates to the field of network communications and in particular relates to a method and a device for selecting a communication interface for the routing of data.
  • a laptop can be connected to the Internet by a wired connection, Ethernet type, and a wireless connection (Wifi) simultaneously.
  • a cell phone is connected to the Internet both by its Wifi antenna and by its 3G antenna.
  • an interface of the equipment is selected for transmission. The choice can be made for example on the first interface of the list of existing interfaces on the equipment. The chosen interface depends on the policy put in place by the operating system installed on the equipment. However, the selected interface can lead to a bad exploitation of network resources, leading to a deterioration in the quality of the network, such as reduced bandwidth, transmission delays, and data loss.
  • a non-optimal data routing may involve retransmission of the data and then induce an increase of the data. energy consumption of network equipment.
  • patent application WO 2010/097057 to Sarikaya et al. provides a method for configuring a multi-interface host and selecting an interface based on routing information contained in a Dynamic Host Configuration Protocol (DHCP) message.
  • DHCP Dynamic Host Configuration Protocol
  • such an approach is limited to a local view of the host, and the selected interface is the one that offers the most advantageous metric of the immediate link.
  • a router (first node 211) with multiple interfaces is used to send routing messages that contain the network view as perceived by that node, and listen to messages from other nodes. After receiving all the messages, the first node calculates the best paths based on the power consumption, and stores them in a routing table.
  • This method operates according to routing protocols such as Open Short Path Path First (OSPF) or IS-IS
  • the disadvantage of one method is that its application is limited to the core network, the dynamic routing protocols such as OSPF not being applicable to the edge of a network, that is to say the equipment carried by a network.
  • user such as a smartphone or tablet, or end-system computers.
  • a local network such as a home network or an enterprise network is generally narrower in terms of network resources than a core network such as an Internet Service Provider (ISP), and the optimization of the network. routing of data within such a local network is therefore more critical.
  • ISP Internet Service Provider
  • An object of the present invention is to provide an interface selection method that allows a multi-user user equipment to select the most appropriate transmission interface to optimize data routing within a network. local.
  • Another object of the present invention is to provide a method that combines a protocol adapted to the end devices, such as the Neighbor Discovery protocol in English with a network core protocol, such as the OSPF protocol, using the same cost metric.
  • the metric can characterize the energy of the communication links, that is to say the amount of energy corresponding to issuing a data packet on the link, but can also rely on any type of metrics associated with network links such as quality of service metrics (bandwidth, latency, packet loss rate) or security (security level on the link).
  • quality of service metrics bandwidth, latency, packet loss rate
  • security security level on the link
  • the present invention avoids the porting on an end terminal (or "end system" in English) of an expensive routing protocol, in terms of computing and storage resources.
  • the invention does not present a security risk as to a compromise of the routing tables since its method does not require that the multi-interface host node explicitly participate in the routing protocol.
  • the present invention will be implemented in contexts where multi-interface terminals must send data within a network. In particular, it will benefit in the following areas:
  • ad-hoc multi-hop networks mainly wireless, and in particular those grouping different types of radio or wired links;
  • the present invention allows multi-interface terminals to communicate effectively within the ad-hoc network, that is to say to benefit from an optimal routing of the traffic without having to execute locally the ad-hoc routing protocol, such as OLSR (Optimized Link State Routing) for example.
  • OLSR Optimized Link State Routing
  • the present invention can be applied to tablets as well as to multi-interface mobile routers.
  • a multi-interface mobile router is understood as a communication bridge embedded in a vehicle and interconnecting one or more networks internal to the vehicle to the external infrastructure via various network interfaces.
  • the invention applies in a communication network consisting of a plurality of routers connected by communication links and comprising at least one source host equipped with several communication interfaces for transmitting and receiving data, each interface being connected to a router of the communication network via a communication link having a link cost.
  • the claimed method for selecting an interface of the source host for transmitting data to a destination host connected to the communication network comprises the steps of:
  • RA advertisement message
  • the route cost announcement (RA) message receiving step includes a step of verifying whether the received advertisement (RA) message contains a route cost option, or ignoring the message.
  • an initial step makes it possible to determine the link cost of each link between each interface of the source host and the router to which said interface is connected and to select the interface having the lowest link cost as an interface. by default.
  • an identifier of the selected interface is stored in a routing table of the source host.
  • the step of selecting a default interface is to receive on each interface of the source host an announcement message (RA) of the router to which said interface is connected which includes a cost value calculated according to a link cost calculation metric defined for said network of links.
  • RA announcement message
  • IPv6 IPv6 protocol
  • ND neighborhood discovery protocol
  • the link cost is calculated for different routing metrics and the message of
  • RS solicitation
  • the invention further relates to a system for selecting a communication interface, the system comprising means for implementing all the steps of the claimed method.
  • the invention may operate in the form of a computer program product that includes code instructions for performing the claimed process steps when the program is run on a computer.
  • Figure 1 schematically shows a source host connected to several routers via different links in a communication network
  • Figures 2a and 2b show the procedures performed by the routers and the source host of Figure 1 for selection of a default interface;
  • Figure 3 schematically shows an example of different routes between a source host and a recipient host;
  • Figure 4 shows the message exchanges involved for the selection of a route in the example of Figure 3;
  • Figure 5 shows the procedures performed by a router in the example of Figure 3;
  • Figure 6 shows the procedures performed by the source host in the example of Figure 3.
  • IPv6 address The unique identifier of a node in the network.
  • the IPv6 address consists of two parts: a prefix on the left and an interface identifier on the right.
  • Link cost The metric associated with the link.
  • DHCPv6 Dynamic Host Configuration Protocol for IPv6
  • Dynamic configuration protocol for hosts in a network. It allows to assign a complete IPv6 address to a host.
  • Host Terminal equipment of a user who has at least one communication interface to transmit / receive data and which does not allow data routing.
  • Interface Identifier The right part of the IPv6 address of a node that identifies it on a link.
  • the Interface Identifier must be unique among all the Interface Identifiers on the same link.
  • Link Direct physical connection between two nodes.
  • the connection can be wired (Ethernet cable, fiber optic, etc.) or wireless
  • Metric Non-zero positive value associated with a link. It describes the link and compares it to other links in the network. Examples of metrics for a link are: throughput, loss rate, delay, level of security, energy, and so on. A particular example is the amount of energy corresponding to the transmission of an IP packet on this link. The metric is used by the routing protocols in the calculation of the best routes: the higher the metric of a link, the more the link in question will be avoided because, in general, a high metric reflects a link of poor quality.
  • MTU Maximum Transmission Unit
  • Neighbor Discovery A link-wide routing protocol (also known as "one-hop” routing) that allows the configuration of a host that connects to the network.
  • Node Any communicating IPv6 equipment (router or host) connected to the network.
  • Prefix The left part of the IPv6 address of a node that identifies a specific link in the network.
  • the prefix is the part used by routers to route traffic to a destination. It must be unique within the network and shared by nodes connected to the same link.
  • Router Advertisement Signaling message of the ND protocol sent by a router, either periodically and to all the nodes present on the link (multicast communication), or in response to an RS transmitted by a specific node (unicast communication).
  • Router A communicating device with at least two communication interfaces and whose role is to route data packets from one node to another in the network.
  • Router Solicitation Signaling message of the ND protocol issued by a host and destined for one or all routers on the link.
  • SLAAC State Less Address Auto Configuration
  • FIG. 1 illustrates an example of a network communication infrastructure 100 in which it is advantageous to implement the invention.
  • the example of FIG. 1 shows only a finite number of hosts and routers, but the skilled person will extend the principles described to a plurality and a variety of hosts (102-i), routers (104-i) and number and type of connection links.
  • a host (102) is connected by a first interface (103) to a first router (104-1) via a first link (106) and a second interface (105) to a second router (104-2) via a second link (108).
  • Each router can itself be connected to other nodes of the network via different links (110).
  • the host (102) retrieves from each router present on the link to which it is connected, the information necessary for its configuration such as an IPv6 prefix, the selection of a default route, its auto -configuration by SLAAC or DHCPv6, or the size of the MTU.
  • Each router provides the host with the parameters necessary for its configuration.
  • the Neighborhood Discovery Protocol handles this information exchange through Router Solicitation (RS) messages, and Router Advertisement messages (RA). ), or "Router Advertisement" in English.
  • RS Router Solicitation
  • RA Router Advertisement messages
  • the skilled person can refer to the "Request for
  • Figures 2a and 2b show the procedures performed by the routers (104-1, 104-2) and the source host (102) of Figure 1 for selection of a default interface on the source host.
  • a router transmits (202) an announcement message (RA) on its link to the source host.
  • the message contains in a new option the cost of the link.
  • the link cost or "Link Cost" in English is included in a field of the new message option (RA) as a non-integer signed 32-bit, as schematically shown below for an IPv6-based message (RA):
  • Type Code identifying the option. Unsigned 8-bit integer.
  • Length The length of the option. Unsigned 8-bit integer. Reserved: Field not used, set to zero by the sender. Link Cost: Cost of the link. Unsigned 32-bit integer.
  • the announcement message (RA) is sent periodically (204) on the link.
  • RFC 4861 which defines the "ND" protocol, the period for sending RA messages is arbitrary but must be at least 3 seconds. The value of this sending period that can be configured by a network administrator does not affect the operation of the present invention.
  • Figure 2b shows the steps taken at the host (102) to allow it to select its default interface based on the routing metric used in the network.
  • the host receives (2002) an advertisement message (RA) from a router on one of its interfaces (I).
  • the method verifies (2004) whether the received message contains a link cost indication. If there is no option in the received message, the process waits for the reception of a new message (NO branch).
  • the process continues to the next step (2006) where it checks whether a default interface is assigned. If no interface is assigned, the method selects (2008) the current interface (I) as the default interface (ID). This information is stored (2010) in the routing table of the host.
  • the method compares in a next step (2012) the cost of the link received on the current interface (I) at the cost of the link on the default interface (ID). If the link cost of the current interface is lower than the cost of the link of the default interface (YES branch), the process selects (2008) the current interface as the default interface (ID) and updates its routing table (2010) by memorizing an identifier of the selected interface.
  • the process retains the default interface and waits for a next message (RA).
  • the host upon receipt of a message (RA) containing the link cost option on an interface, the host assigns the cost of the link announced in the message to this interface. It then sets its default interface by selecting the one with the lowest cost.
  • routers issue periodic RA messages.
  • the first router (104-1) transmits on the first link (106) an announcement message (RA1) that includes the link cost option, with a link cost value of "5".
  • the second router (104-2) transmits on the second link (108) an advertisement message (RA2) which includes the cost option of the link, with a Link cost value of "3".
  • Figure 3 schematically shows an example of different possible routes between a source host (102) and a destination host (302).
  • the recipient host (302) is connected to the first router (104-1) by a link (304) that has a value link cost "2".
  • the elements in common with Figure 1 retain the same references and are not described again.
  • the source host has a default interface selected according to the network routing metric, the systematic use of the same for all its communications may not be optimal on an end-to-end path taken by the data. .
  • the host being connected on different links of the network thanks to its different interfaces, the use of its default interface for certain communications can generate "detours" according to the location of the destination node in the network and therefore generate additional costs.
  • the method of the invention provides the source host with a more global view of the end-to-end path to the host. destination by allowing it to compare the cost of each possible route to the recipient host and select the best route.
  • Figure 4 shows the message exchanges occurring between the different entities of Figure 3 for the selection of a route.
  • the source host receives on each of its interfaces (11, I2) announcement messages (RA1, RA2) respectively connected routers (R1, R2) containing the corresponding values of cost of the link.
  • the source host selects its default interface according to the method of Figure 2b.
  • the source host (H1) wishes to transmit data to a destination (H2), if no entry to this destination exists in its routing table, it sends a request (RS1, RS2) on each of its interfaces to request to the respective routers the cost of the end-to-end path to the destination (H2).
  • the routers respond by sending each an announcement message (RA11, RA12) respectively announcing the cost of the shortest path to their knowledge to reach said destination.
  • RA11, RA12 an announcement message
  • response messages to the route cost request preferentially contain:
  • the IPv6 address of the destination if the routing policy implemented is of routing type based on the host address or "host-based routing";
  • the routing policy implemented is of standard routing type based on prefixes or "network-based routing".
  • the cost announcement messages preferentially contain the indication of road cost or "Path Cost" in English, according to the format shown schematically below: 0 1 2 3
  • Length The length of the option. Unsigned 8-bit integer.
  • Transaction ID Number identifying the exchange of RS / RA messages between host and router. Unsigned 8-bit integer.
  • the option contained in an RA message sent in response to an RS message must contain the same transaction number as that contained in the RS message option.
  • Prefix Length Unsigned 8-bit integer.
  • RA message contains the prefix length of the Destination Ad- dress / Prefix field. Zeroed in an RS message.
  • RA message IPv6 address of the destination or prefix corresponding to this destination according to the routing policy implemented ("host-based routing” or “network-based routing”).
  • Path Cost The cost of the end-to-end path from the router that sends the RA message to the destination. Unsigned 32-bit integer. Zeroed in an RS message.
  • Figure 5 shows the procedures performed by a router to advertise the cost of a route to a destination (D) required by a source host.
  • step (504) Upon receipt (502) of a Router Solicitation (RS) message sent by a source host, the method verifies in step (504) whether the route cost indication option is enabled. If the option is not activated (NO branch), the process waits for the receipt of a new prompt. If the route cost indication option is enabled (YES branch), the method proceeds to the next step (506) to check if there is a route registered in the routing table of the router for the destination required. If there is no recorded route (NOT branch), a message (RA) is sent to the source host at step (508) indicating in the "Status Code" field that there is no road. The field "Path Cost" is set to zero.
  • FIG. 6 shows the procedures performed by a source host to select a route for sending data to a destination host.
  • the process begins when a source host has to send data to a destination host (D).
  • the source host generates (step 602) a route cost prompt (RSi) for the requested destination from each of its interfaces.
  • RSi route cost prompt
  • the method Upon receipt (604) of an announcement message (RA1 or RA2 of Fig. 4) on an interface, the method verifies (step 606) whether the route cost option is enabled in the message. If the option is not activated (NO branch), the process resumes at the beginning. If the option is enabled (YES branch), the method proceeds to the next step (608) where it checks whether an identifier (ID) of another interface is already registered in the routing table of the source host for the required destination. If no interface is selected (NO branch), the method allocates the message receiving interface for the requested destination (step 610) and proceeds to update the host routing table (step 612) by storing an identifier for the allocated interface.
  • ID identifier
  • step 608 if an interface (ID) is already allocated (YES branch), the method calculates (step 614) the total road cost for transmitting the data via the reception interface of the announcement message by taking into account account the link cost of the corresponding link of the router. Then, the process compares (step 616) the total route cost via the announcement message receiving interface (RA), at the total route cost via the registered interface (ID).
  • the method selects the new interface (step 610) for sending data to the requested destination and sets update its routing table (step 612), otherwise (branch NO), the method maintains the interface (ID) allocated and stops.
  • the sending host (102) which must send data to the destination host (302) while it does not have a specific route to this host in its routing table , issues a solicitation message (RS) containing the route cost option to the host (302) on each of its interfaces (103, 105).
  • Each router responds with an advertisement message (RA) containing the cost of the best path it has to reach the recipient host (302).
  • the first router (104-1) responds with a value link cost "2" via the link 304, while the second router (104-2) responds with a total value link cost "6" via the links ( 110) and (304).
  • the source host is already aware of the cost of the first and second links (106) and (108) by the routers.
  • the route from the first interface (103) via the first router (104-1) returns to a total route cost of value "7" and the route from the second interface (105) via the second router (104-2) returns to a total road cost of value "9".
  • the first interface (103) is selected by the source host to transmit the data to the destination host (302). This information is stored as a new entry in the routing table of the source host.
  • either the identity of the recipient host is registered if it is a "host-based routing" policy, or the link identifier to the destination host is saved if This is a Network-based routing policy.
  • the routers have different routing tables, each of which is associated with a different metric / cost, such as bandwidth, latency, loss rate of packets, the level of link security, the transmission energy of a packet on the link, to name a few.
  • multi-metric routing can for example be achieved by using several instances having different metrics, on the same routing protocol (for example OSPF, IS-IS) or on different routing protocols in the same network.
  • the (RA) messages sent by the routers include the costs associated with several metrics or all routing metrics used in the network.
  • the message contains for each of them a metric identifier and a link cost associated with this metric.
  • the multi-interface host node can thus configure in its local routing table a default route for each of the metrics of routing.
  • the format of the multi-metric cost announcement option of a message is schematically illustrated below, where the fields “Metric ID i" represent the identifier of the metric T considered and the fields “Link” Cost i "represents the cost of the link associated with the metric T.
  • the step of discovering the cost of the routes includes the possibility for the multi-interface host node to specify in the message (RS) destined for its neighboring routers the metric or metrics it wishes to take into account. for determining the cost of the end-to-end route to a given destination, indicating the identifier (s) of the metrics in the message (RS). Neighboring routers respond by indicating in their messages (RA) the identifiers of the metrics associated with the costs of the routes to the destination according to each of the metrics requested. Based on the received messages, the multi-interface host node can configure in its local routing table an optimal route to a given destination for one or several specific routing metrics.
  • the fields "Metric ID i" represent the identifier of the metric ⁇ 'considered and the fields “Path Cost i” represent the cost of the route associated with the metric ⁇ ', the fields “Lifetime i” represent the duration of validity in seconds of the information announced in the message (RA) and the fields “Traffic Tag i” represent the traffic marking to be applied to data packets to be routed according to the associated metric T.
  • This information allows the host node to know which markup to apply to its data packets to benefit from routing according to a particular metric.
  • the standards I Pv4 and I Pv6 define fields dedicated to marking packages. These are located in the IP header of the packets on the "Differentiated Services Code Point (DSCP)" fields for IPv4 and "Traffic Class” and "Flow Label” for IPv6.
  • DSCP Differentiated Services Code Point
  • the present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium.
  • the support can be electronic, magnetic, optical, electromagnetic or be an infrared type of diffusion medium.
  • Such supports are, for example, Random Access Memory RAMs (ROMs), magnetic or optical tapes, disks or disks (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read / Write (CD-R / W) and DVD).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

La présente invention concerne un procédé et un dispositif qui permet de sélectionner l'interface d'un hôte source afin de transmettre de manière optimale des données à un hôte de destination. Le procédé permet à l'hôte source de calculer le coût de route total vers l'hôte de destination depuis chacune de ses interfaces, en fonction des métriques de routage, et à sélectionner l'interface correspondant à la valeur de coût de route total la plus basse.

Description

PROCEDE ET DISPOSITIF DE SELECTION D'INTERFACE DE
COMMUNICATION
Domaine de l'invention
L'invention concerne le domaine des communications réseau et en particulier porte sur un procédé et un dispositif pour sélectionner une interface de communication pour le routage de données. Etat de la Technique
Avec le développement toujours plus poussé de l'électronique, des technologies de l'information et de la communication, la commercialisation d'appareils communicants équipés de plusieurs interfaces de communication différentes est courante. Par exemple, un ordinateur portable peut être connecté à l'Internet par une connexion filaire, de type Ethernet, et par une connexion sans fil (Wifi) simultanément. Un téléphone cellulaire est connecté à l'Internet à la fois par son antenne Wifi et par son antenne 3G. Lorsque l'utilisateur d'un tel équipement souhaite émettre des données, une interface de l'équipement est sélectionnée pour l'émission. Le choix peut se faire par exemple sur la première interface de la liste des interfaces existantes sur l'équipement. L'interface retenue dépend de la politique mise en place par le système d'exploitation installé sur l'équipement. Or l'interface sélectionnée peut conduire à une mauvaise exploitation des ressources du réseau, menant à une dégradation de la qualité du réseau, telle qu'une bande passante réduite, des délais de transmissions, des pertes de données.
Par ailleurs, un routage de données non optimal peut impliquer une retransmission des données et alors induire une augmentation de la consommation d'énergie des équipements du réseau.
Des solutions pour permettre une sélection plus optimale d'une interface sur un hôte multi-interfaces existent. Ainsi, la demande de brevet WO 2010/097057 de Sarikaya et al. propose une méthode pour configurer un hôte multi-interfaces et sélectionner une interface en se basant sur des informations de routage contenues dans un message Dynamic Host Configuration Protocol (DHCP). Cependant, une telle approche se limite à une vision locale de l'hôte, et l'interface sélectionnée est celle qui propose la métrique la plus avantageuse du lien immédiat.
Dans la demande internationale de brevet WO 2012/087184 de Telefonaktiebolaget LM Ericsson intitulée « Energy Efficient Routing and Switching », une méthode pour réaliser un routage basé sur une métrique de consommation énergétique est présentée. Un routeur (premier nœud 211 ) doté de plusieurs interfaces est utilisé pour envoyer des messages de routage qui contiennent la vue du réseau telle que perçue par ce nœud, et écouter les messages des autres nœuds. Après avoir reçu tous les messages, le premier nœud calcule les meilleurs chemins en se basant sur la consommation énergétique, et les stocke dans une table de routage. Cette méthode opère selon des protocoles de routage tels que l'Open Shortest Path First (OSPF) ou l'IS-IS
(Intermediate System to Intermediate System). L'inconvénient d'une méthode est que son application est limitée au réseau cœur, les protocoles de routage dynamique comme l'OSPF n'étant pas applicables au bord d'un réseau, c'est-à-dire aux équipements portés par un utilisateur, comme un smartphone ou une tablette, ou à des ordinateurs « end Systems ».
Les solutions connues présentent aussi un inconvénient lié à la sécurité du routage des données dans le réseau. En effet, les échanges des protocoles de routage ne s'effectuent qu'entre des routeurs du réseau qui sont sous le contrôle strict de l'opérateur de réseau. Les messages de routage étant généralement authentifiés pour éviter toute compromission des tables de routage des routeurs, tout nœud hôte ne peut pas participer directement au protocole de routage en prenant le risque de
compromettre la sécurité du routage dans le réseau de l'opérateur.
Par ailleurs, un réseau local tel un réseau domestique ou un réseau d'entreprise est généralement plus restreint en termes de ressources réseau qu'un réseau de cœur comme celui d'un Fournisseur d'Accès Internet (FAI), et l'optimisation du routage des données au sein d'un tel réseau local est donc plus critique.
Ainsi, les approches connues ne répondent pas à l'ensemble des besoins d'optimisation de routage des données. L'invention proposée permet de répondre à ces besoins.
Résumé de l'invention
Un objet de la présente invention est de proposer un procédé de sélection d'interface qui permet à un équipement utilisateur multi- interfaces de sélectionner l'interface d'émission la plus appropriée afin d'optimiser le routage de données au sein d'un réseau local.
Un autre objet de la présente invention est de proposer un procédé qui combine un protocole adapté aux équipements finaux, comme le protocole de découverte de voisinage - « Neighbor Discovery » en anglais - avec un protocole de cœur réseau, comme le protocole OSPF, en utilisant la même métrique de coûts.
Avantageusement, la métrique peut caractériser l'énergie des liens de communication, c'est-à-dire la quantité d'énergie correspondant à l'émission d'un paquet de données sur le lien, mais peut aussi s'appuyer sur tout type de métriques associées aux liens du réseau telles que des métriques de qualité de service (bande passante, latence, taux de pertes de paquets) ou de sécurité (niveau de sécurité sur le lien).
Avantageusement la présente invention évite le portage sur un terminal final (ou « end System » en anglais) d'un protocole de routage coûteux, en termes de ressources de calcul et stockage. Avantageusement, l'invention ne présente pas de risque de sécurité quant à une compromission des tables de routage puisque son procédé ne nécessite pas que le nœud hôte multi-interfaces participe explicitement au protocole de routage. Avantageusement, la présente invention s'implémentera dans les contextes où des terminaux multi-interfaces doivent envoyer des données au sein d'un réseau. En particulier, elle trouvera avantage dans les domaines suivants :
les réseaux domestiques ;
- les réseaux d'entreprise ;
les systèmes cellulaires regroupant diverses technologies d'accès radio ;
les réseaux ad-hoc multi-sauts, principalement sans-fil, et en particulier ceux regroupant différents types de liens radio ou filaires;
- les réseaux véhiculaires.
Dans le contexte des réseaux ad-hoc, la présente invention permet à des terminaux multi-interfaces de communiquer efficacement au sein du réseau ad-hoc, c'est-à-dire de bénéficier d'un routage optimal du trafic sans avoir à exécuter localement le protocole de routage ad-hoc, comme le protocole OLSR (Optimized Link State Routing) par exemple. Dans le contexte des réseaux véhiculaires, la présente invention peut s'appliquer à des tablettes, ainsi qu'à des routeurs mobiles multi- interfaces. Un routeur mobile multi-interfaces est compris comme une passerelle de communication embarquée dans un véhicule et interconnectant un ou plusieurs réseaux internes au véhicule à l'infrastructure externe via diverses interfaces réseaux.
Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés.
En particulier, l'invention s'applique dans un réseau de communication constitué d'une pluralité de routeurs connectés par des liens de communication et comprenant au moins un hôte source équipé de plusieurs interfaces de communication pour émettre et recevoir des données, chaque interface étant connectée à un routeur du réseau de communication via un lien de communication ayant un coût de lien. Le procédé revendiqué pour sélectionner une interface de l'hôte source pour transmettre des données à un hôte de destination connecté au réseau de communication, comprend les étapes de:
- émettre depuis chaque interface de l'hôte source un message de
sollicitation (RS) vers le routeur auquel ladite interface est connectée, pour demander le coût de route vers l'hôte de destination ;
- recevoir sur l'interface correspondante de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée donnant une valeur du coût de route depuis ledit routeur vers l'hôte de destination ;
- calculer à partir des valeurs reçues et de la valeur de coût de lien du lien correspondant, la valeur du coût de route total vers l'hôte de destination depuis l'hôte source pour chaque interface;
- comparer les valeurs de coût de route total obtenues ; et - sélectionner l'interface correspondant à la valeur de coût de route total la plus basse.
Dans une variante, l'étape de réception de message d'annonce de coût de route (RA) comprend une étape pour vérifier si le message d'annonce (RA) reçu contient une option de coût de route, ou ignorer le message.
Dans une autre variante, une étape initiale permet de déterminer le coût de lien de chaque lien entre chaque interface de l'hôte source et le routeur auquel ladite interface est connectée et de sélectionner l'interface ayant le coût de lien le plus faible comme interface par défaut.
De manière préférentielle, un identifiant de l'interface sélectionnée est stocké dans une table de routage de l'hôte source.
Dans une variante d'implémentation, l'étape de sélection d'une interface par défaut consiste à recevoir sur chaque interface de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée qui comprend une valeur de coût de lien calculée selon une métrique de calcul de coût de lien définie pour ledit réseau de
communication. Avantageusement, le protocole dudit réseau de
communication est le protocole IPv6, et l'étape de sélection d'une interface par défaut se fait selon un protocole de découverte de voisinage (ND).
Dans une autre variante d'implémentation, le coût de lien est calculé pour différentes métriques de routage et le message de
sollicitation (RS) contient une indication du ou des métriques pour lesquels calculer le coût de lien.
L'invention concerne de plus un système pour sélectionner une interface de communication, le système comprenant des moyens pour mettre en œuvre toutes les étapes du procédé revendiqué.
L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur.
Description des figures
Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous :
La figure 1 montre schématiquement un hôte source connecté à plusieurs routeurs via différents liens dans un réseau de communication ;
Les figures 2a et 2b montrent les procédures exécutées par les routeurs et l'hôte source de la figure 1 pour la sélection d'une interface par défaut ; La figure 3 montre schématiquement un exemple de différentes routes entre un hôte source et un hôte destinataire ;
La figure 4 montre les échanges de messages intervenant pour la sélection d'une route dans l'exemple de la figure 3 ;
La figure 5 montre les procédures exécutées par un routeur dans l'exemple de la figure 3 ;
La figure 6 montre les procédures exécutées par l'hôte source dans l'exemple de la figure 3.
Description détaillée de l'invention Pour permettre une bonne compréhension de la description, une terminologie des principaux termes utilisés est donnée ci-après :
Adresse IPv6 : Identifiant unique d'un nœud dans le réseau. L'adresse IPv6 est composée de deux parties : un préfixe en partie gauche et un identifiant d'interface en partie droite.
Coût du lien : Métrique associée au lien.
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) :
Protocole de configuration dynamique des hôtes d'un réseau. Il permet notamment d'attribuer une adresse IPv6 complète à un hôte.
Hôte : Equipement terminal d'un utilisateur qui possède au moins une interface de communication pour émettre/recevoir des données et qui ne permet pas le routage de données.
Identifiant d'Interface : Partie droite de l'adresse IPv6 d'un nœud qui permet de l'identifier sur un lien. L'Identifiant d'Interface doit être unique parmi tous les Identifiants d'Interface sur un même lien.
Lien : Connexion physique directe entre deux nœuds. La connexion peut être filaire (câble Ethernet, fibre optique, etc.) ou sans fil
(ondes radio : wifi, bluetooth, 3G, etc.).
Métrique : Valeur positive non nulle associée à un lien. Elle permet de décrire le lien et de le comparer aux autres liens du réseau. Des exemples de métriques d'un lien sont : le débit, le taux de pertes, le délai, le niveau de sécurité, l'énergie, etc. Un exemple particulier est la quantité d'énergie correspondant à l'émission d'un paquet IP sur ce lien. La métrique est utilisée par les protocoles de routage dans le calcul des meilleures routes : plus la métrique d'un lien est élevée, plus le lien en question sera évité car, en général, une métrique élevée traduit un lien de mauvaise qualité.
Maximum Transmission Unit (MTU) : Taille des données maximum incluses dans un paquet IPv6. Si la quantité de données à transmettre est supérieure à la MTU, les données doivent être fragmentées en plusieurs paquets IPv6.
Neighbor Discovery (ND) : Protocole de routage à échelle du lien (aussi appelé routage « à un saut ») qui permet la configuration d'un hôte qui se connecte au réseau.
Nœud : Tout équipement IPv6 communicant (routeur ou hôte) connecté au réseau.
Préfixe : Partie gauche de l'adresse IPv6 d'un nœud qui permet d'identifier un lien spécifique dans le réseau. Le préfixe est la partie utilisée par les routeurs pour router le trafic vers une destination. Il doit être unique au sein du réseau et est partagé par les nœuds connectés à un même lien.
Router Advertisement (RA) : Message de signalisation du protocole ND émis par un routeur soit périodiquement et à destination de tous les nœuds présents sur le lien (communication multicast), soit en réponse à un RS émis par un nœud spécifique (communication unicast).
Routeur : Equipement communicant doté d'au moins deux interfaces de communication et dont le rôle est de router les paquets de données d'un nœud à un autre dans le réseau.
Router Solicitation (RS) : Message de signalisation du protocole ND émis par un hôte et à destination d'un ou de tous les routeurs présents sur le lien.
State Less Address Auto Configuration (SLAAC) : Mécanisme permettant à un hôte de générer localement la partie Identifiant d'Interface de son adresse IPv6 en se basant sur son adresse MAC. La configuration d'un hôte par SLAAC s'oppose généralement à la configuration par DHCPv6.
La figure 1 illustre un exemple d'infrastructure de communication réseau 100 dans laquelle implémenter avantageusement l'invention. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 1 ne montre qu'un nombre fini d'hôtes et de routeurs, mais l'homme du métier étendra les principes décrits à une pluralité et une variété d'hôtes (102-i), de routeurs (104-i) et de nombre et type de liens de connexion.
Un hôte (102) est connecté par une première interface 11 (103) à un premier routeur (104-1 ) via un premier lien (106) et par une seconde interface 12 (105) à un second routeur (104-2) via un second lien (108). Chaque routeur peut lui-même être connecté sur d'autres nœuds du réseau via différents liens (110).
Pour être connecté au réseau, l'hôte (102) récupère auprès de chaque routeur présent sur le lien auquel il est connecté, les informations nécessaires à sa configuration telles qu'un préfixe IPv6, la sélection d'une route par défaut, son auto-configuration par SLAAC ou DHCPv6, ou encore la taille de la MTU. Chaque routeur fournit à l'hôte les paramètres nécessaires à sa configuration. Dans les réseaux IPv6, le protocole de découverte de voisinage (ND) se charge de cet échange d'informations par des messages de Sollicitation du Routeur (RS) ou « Router Solicitation » en anglais, et des messages d'Annonce du Routeur (RA), ou « Router Advertisement » en anglais. L'homme du métier pourra se référer à la « Request for
Comments » (RFC) 4861 pour une description plus détaillée sur le format et le contenu des messages (RS) et (RA) selon le protocole IPv6.
Les figures 2a et 2b montrent les procédures exécutées par les routeurs (104-1 , 104-2) et l'hôte source (102) de la figure 1 pour la sélection d'une interface par défaut sur l'hôte source.
Un routeur émet (202) un message d'annonce (RA) sur son lien vers l'hôte source. Selon le principe de l'invention, le message contient dans une nouvelle option le coût du lien. Dans une implémentation préférentielle, le coût du lien ou « Link Cost » en anglais, est inclus dans un champ de la nouvelle option du message (RA) comme un entier non signé sur 32 bits, tel que montré schématiquement ci-après pour un message (RA) selon le protocole IPv6:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 Type I Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La signification des champs est la suivante : Type : Code identifiant l'option. Entier non signé sur 8 bits.
Length : Longueur de l'option. Entier non signé sur 8 bits. Reserved : Champ non exploité, mis à zéro par l'émetteur. Link Cost: Coût du lien. Entier non signé sur 32 bits.
Le message d'annonce (RA) est envoyé périodiquement (204) sur le lien. Selon la RFC 4861 qui définit le protocole « ND », la période d'envoi des messages RA est arbitraire mais doit être au minimum de 3 secondes. La valeur de cette période d'envoi qui peut être configurée par un administrateur réseau n'a pas d'impact sur le fonctionnement de la présente invention.
La figure 2b montre les étapes opérées au niveau de l'hôte (102) pour lui permettre de sélectionner son interface par défaut d'après la métrique de routage utilisée dans le réseau. L'hôte reçoit (2002) un message d'annonce (RA) d'un routeur sur l'une de ses interfaces (I). Le procédé vérifie (2004) si le message reçu contient une indication de coût de lien. S'il n'y a pas cette option dans le message reçu, le procédé attend la réception d'un nouveau message (branche NON).
Si le message d'annonce (RA) reçu contient une information de coût du lien (branche OUI), le procédé continue à l'étape suivante (2006) où il vérifie si une interface par défaut est assignée. Si aucune interface n'est assignée, le procédé sélectionne (2008) l'interface (I) en cours comme interface par défaut (ID). Cette information est stockée (2010) dans la table de routage de l'hôte.
Si une interface par défaut (ID) est déjà assignée (branche OUI), le procédé compare dans une étape suivante (2012) le coût du lien reçu sur l'interface (I) en cours au coût du lien sur l'interface par défaut (ID). Si le coût du lien de l'interface en cours est inférieur au coût du lien de l'interface par défaut (branche OUI), le procédé sélectionne (2008) l'interface en cours comme interface par défaut (ID) et met à jour sa table de routage (2010) en mémorisant un identifiant de l'interface sélectionnée.
Si le coût du lien de l'interface en cours est supérieur ou égal au coût du lien de l'interface par défaut (branche NON), le procédé conserve l'interface par défaut et attend un prochain message (RA).
Ainsi, à chaque réception d'un message (RA) contenant l'option de coût du lien sur une interface, l'hôte affecte le coût du lien annoncé dans le message à cette interface. Il définit ensuite son interface par défaut en sélectionnant celle dont le coût est le plus faible. Dans l'exemple de la figure 1 , les routeurs émettent des messages RA périodiques. Le premier routeur (104-1 ) émet sur le premier lien (106) un message d'annonce (RA1 ) qui inclue l'option de coût du lien, avec une valeur de coût de lien de « 5 ». Le second routeur (104-2) émet sur le second lien (108) un message d'annonce (RA2) qui inclue l'option de coût du lien, avec une valeur de coût de lien de «3 ». Ces messages permettent à l'hôte (102) d'affecter la valeur de coût de lien « 5 » à son interface 11 (103) et la valeur de coût de lien « 3 » à son interface 12 (105). Le procédé implémenté permet que l'interface 12 soit sélectionnée comme interface par défaut car ayant le coût de lien le plus faible.
La figure 3 montre schématiquement un exemple de différentes routes possibles entre un hôte source (102) et un hôte destinataire (302). L'hôte destinataire (302) est connecté au premier routeur (104-1 ) par un lien (304) qui a un coût de lien de valeur « 2 ». Les éléments en commun avec la figure 1 conservent les mêmes références et ne sont pas décrits de nouveau. Dans l'exemple de la figure 3, il existe un lien (110) entre les deux routeurs (104-1 , 104-2) qui a un coût de valeur « 4 ». Bien que l'hôte source ait une interface par défaut sélectionnée selon la métrique de routage du réseau, l'utilisation systématique de celle-ci pour toutes ses communications peut ne pas être optimale sur un chemin de bout-en-bout emprunté par les données. En effet, l'hôte étant connecté sur différents liens du réseau grâce à ses différentes interfaces, l'utilisation de son interface par défaut pour certaines communications peut engendrer des « détours » en fonction de l'emplacement du nœud destination dans le réseau et donc engendrer des coûts supplémentaires. Afin que l'hôte source soit en mesure de sélectionner une interface pour une communication optimale vers un hôte destinataire, le procédé de l'invention permet de donner à l'hôte source une vision plus globale du chemin de bout-en-bout vers la destination en lui permettant de comparer le coût de chaque route possible vers l'hôte destinataire et de sélectionner la meilleure route.
La figure 4 montre les échanges de messages intervenant entre les différentes entités de la figure 3 pour la sélection d'une route. Dans une étape préliminaire, l'hôte source (H1 ) reçoit sur chacune de ses interfaces (11 , I2) des messages d'annonce (RA1 , RA2) respectivement des routeurs connectés (R1, R2) contenant les valeurs correspondantes de coût du lien. L'hôte source sélectionne son interface par défaut selon le procédé de la figure 2b.
Lorsque l'hôte source (H1) souhaite émettre des données vers une destination (H2), si aucune entrée vers cette destination n'existe dans sa table de routage, il émet une requête (RS1, RS2) sur chacune de ses interfaces pour demander aux routeurs respectifs le coût du chemin de bout-en-bout vers la destination (H2).
Les routeurs répondent en envoyant chacun un message d'annonce (RA11, RA12) annonçant respectivement le coût du chemin le plus court à leur connaissance pour atteindre ladite destination.
De plus, les messages de réponse à la requête de coût de route contiennent de manière préférentielle :
- soit l'adresse IPv6 de la destination si la politique de routage mise en œuvre est de type routage basé sur l'adresse de l'hôte ou « host- based routing » ;
- soit le préfixe et sa taille correspondant à l'adresse destination si la politique de routage mise en œuvre est de type routage classique basé sur les préfixes ou « network-based routing ».
Les messages d'annonce de coût contiennent de manière préférentielle l'indication de coût de route ou « Path Cost » en anglais, selon le format représenté schématiquement ci-après : 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I Length | Transaction I D | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Reserved I Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+
I I I Destination | I Address or Prefix I
I I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Path Cost I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Lifetime I
La signification des champs est la suivante :
Code identifiant l'option. Entier non signé sur 8 bits.
Length Longueur de l'option. Entier non signé sur 8 bits.
Transaction ID Numéro identifiant l'échange de messages RS/RA entre hôte et routeur. Entier non signé sur 8 bits. L'option contenue dans un message RA envoyé en réponse à un message RS doit contenir le même numéro de transaction que celui contenu dans l'option du message RS.
Status Code Code qui donne des informations complémentaires à la réponse tel que « adresse destination demandée inaccessible », « transaction réussie ». Entier non signé sur 8 bits. Mis à zéro dans un message RS.
Reserved Champ non exploité, mis à zéro par l'émetteur et ignoré par le récepteur.
Prefix Length Entier non signé sur 8 bits. Dans un message RA, contient la longueur du préfixe du champ Destination Ad- dress/Prefix. Mis à zéro dans un message RS. Destination Dans un message RS : adresse IPv6 de la destination Address or
pour laquelle le coût du chemin est demandé. Dans un Prefix
message RA : adresse IPv6 de la destination ou bien préfixe correspondant à cette destination selon la politique de routage mise en œuvre (« host-based routing » ou « network-based routing »).
Path Cost Coût du chemin de bout-en-bout depuis le routeur qui émet le message RA jusqu'à la destination. Entier non signé sur 32 bits. Mis à zéro dans un message RS.
Lifetime Durée de validité en secondes de l'information annoncée dans le RA. Mis à zéro dans un message RS.
Revenant à la figure 4, quand tous les messages de réponse de coût de route (RA11 , RA21 ) sont reçus par l'hôte source (H1 ), celui-ci exécute le procédé qui est décrit plus loin en référence à la figure 6 pour sélectionner l'interface correspondant à la route choisie pour l'envoi des données entre l'hôte source (H1 ) et l'hôte destinataire (H2).
La figure 5 montre les procédures exécutées par un routeur pour annoncer le coût d'une route vers une destination (D) requise par un hôte source.
A réception (502) d'un message de Sollicitation du Routeur (RS) envoyée par un hôte source, le procédé vérifie à l'étape (504) si l'option d'indication de coût de route est activée. Si l'option n'est pas activée (branche NON) le procédé attend la réception d'un nouveau message de sollicitation. Si l'option d'indication de coût de route est activée (branche OUI), le procédé poursuit à l'étape suivante (506) pour vérifier s'il existe une route enregistrée dans la table de routage du routeur pour la destination requise. S'il n'existe pas de route enregistrée (branche NON), un message (RA) est envoyé à l'hôte source à l'étape (508) indiquant dans le champ « Status Code » qu'il n'existe pas de route. Le champ « Path Cost » est mis à zéro.
S'il existe une route enregistrée vers la destination requise
(branche OUI), le procédé passe à l'étape suivante (510) où un message de réponse (RA) est envoyé à l'hôte source indiquant la valeur du coût de la route dans le champ « Path Cost ». Puis le procédé s'arrête. La figure 6 montre les procédures exécutées par un hôte source pour sélectionner une route pour l'envoi de données vers un hôte destinataire.
Le procédé débute quand un hôte source doit envoyer des données vers un hôte destinataire (D). L'hôte source génère (étape 602) un message de sollicitation (RSi) de coût de route pour la destination requise depuis chacune de ses interfaces.
A réception (604) d'un message d'annonce (RA1 ou RA2 de la figure 4) sur une interface, le procédé vérifie (étape 606) si l'option de coût de route est activée dans le message. Si l'option n'est pas activée (branche NON), le procédé reprend au début. Si l'option est activée (branche OUI), le procédé passe à l'étape suivante (608) où il vérifie si un identifiant (ID) d'une autre interface est déjà enregistré dans la table de routage de l'hôte source pour la destination requise. Si aucune interface n'est sélectionnée (branche NON), le procédé alloue l'interface de réception du message pour la destination requise (étape 610) et procède à la mise à jour de la table de routage de l'hôte (étape 612) en mémorisant un identifiant pour l'interface allouée.
A l'étape 608, si une interface (ID) est déjà allouée (branche OUI), le procédé calcule (étape 614) le coût de route total pour transmettre les données via l'interface de réception du message d'annonce en prenant en compte le coût de lien du lien correspondant du routeur. Puis, le procédé compare (étape 616) le coût de route total via l'interface de réception du message d'annonce (RA), au coût de route total via l'interface (ID) enregistrée.
Si le coût de route total calculé est inférieur au coût de route total via l'interface (ID) déjà enregistrée (branche OUI), le procédé sélectionne la nouvelle interface (étape 610) pour l'envoi de données vers la destination requise et met à jour sa table de routage (étape 612), sinon (branche NON), le procédé maintient l'interface (ID) allouée et s'arrête.
Ainsi sur l'exemple de la figure 3, l'hôte émetteur (102) qui doit envoyer des données à l'hôte destinataire (302) alors qu'il ne possède pas de route spécifique à destination de cet hôte dans sa table de routage, émet un message de sollicitation (RS) contenant l'option de coût de la route à destination de l'hôte (302), sur chacune de ses interfaces (103, 105). Chaque routeur lui répond par un message d'annonce (RA) contenant le coût du meilleur chemin dont il dispose pour atteindre l'hôte destinataire (302). Le premier routeur (104-1 ) répond avec un coût de lien de valeur « 2 » via le lien 304, tandis que le second routeur (104-2) répond avec un coût de lien de valeur totale « 6 » via les liens (110) et (304). L'hôte source a déjà connaissance du coût des premier et second liens (106) et (108) par les routeurs. Il calcule alors le coût total pour atteindre l'hôte destinataire. Dans l'exemple choisi, la route depuis la premier interface (103) via le premier routeur (104-1 ) revient à un coût de route total de valeur « 7 » et la route depuis la seconde interface (105) via le second routeur (104-2) revient à un coût de route total de valeur « 9 ». La première interface (103) est sélectionnée par l'hôte source pour émettre les données à destination de l'hôte destinataire (302). Cette information est mémorisée comme une nouvelle entrée dans la table de routage de l'hôte source.
Selon la politique de routage mise en place, soit l'identité de l'hôte destinataire est enregistrée s'il s'agit d'une politique de type « Host-based routing », soit l'identifiant de lien vers l'hôte destinataire est enregistré s'il s'agit d'une politique de type « Network-based routing ».
L'homme de l'art appréciera que des variations peuvent être apportées sur la méthode telle que décrite de manière préférentielle et sur un exemple non limitatif, tout en maintenant les principes de l'invention. Ainsi, les exemples décrits sont basés sur une sélection de route selon une métrique/coût non précisé, et il est possible d'appliquer les mêmes principes sur différents métriques. De même, l'exemple choisi est basé sur le protocole IPv6, mais les mêmes principes restent applicables au protocole IPv4.
Dans une variante d'implémentation avec choix de routage multi- métrique, les routeurs possèdent différentes tables de routage, chacune d'elles étant associée à un métrique/coût différent, comme par exemple la bande passante, la latence, le taux de perte des paquets, le niveau de sécurité du lien, l'énergie de transmission d'un paquet sur le lien, pour n'en citer que quelques uns. Dans cette variante, le routage multi- métrique peut par exemple être réalisé en utilisant plusieurs instances ayant des métriques différentes, sur un même protocole de routage (par exemple OSPF, IS-IS) ou sur des protocoles de routage différents dans un même réseau.
Pour cette variante, dans l'étape d'annonce du coût du lien et de la sélection d'interface par défaut (figures 2a, 2b), les messages (RA) envoyés par les routeurs, incluent les coûts associés à plusieurs métriques ou à toutes les métriques de routage utilisées dans le réseau. Dans le cas ou plusieurs métriques sont annoncées dans un message (RA), le message contient pour chacune d'elle un identifiant de métrique et un coût de lien associé à cette métrique. Sur la base des messages reçus, le nœud hôte multi-interface peut ainsi configurer dans sa table de routage locale une route par défaut pour chacune des métriques de routage.
Le format de l'option d'annonce de coût multi-métrique d'un message (RA) est illustré schématiquement ci-dessous, où les champs « Metric ID i» représentent l'identifiant de la métrique T considérée et les champs « Link Cost i » représentent le coût du lien associé à la métrique T.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Reserved I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Metric ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I ... I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L'étape de découverte du coût des routes (figures 5 et 6) englobe la possibilité pour le nœud hôte multi-interfaces de préciser dans le message (RS) à destination de ses routeurs voisins la ou les métriques qu'il souhaite prendre en compte pour la détermination du coût de la route de bout-en-bout vers une destination donnée, en indiquant le/les identifiant(s) des métriques dans le message (RS). Les routeurs voisins répondent en indiquant dans leurs messages (RA) les identifiants des métriques associés aux coûts des routes vers la destination selon chacune des métriques demandées. Sur la base des messages reçus, le nœud hôte multi-interfaces peut configurer dans sa table de routage locale une route optimale vers une destination donnée pour une ou plusieurs métriques de routage spécifiques.
Le format de l'option d'annonce de coût de route multi-métrique d'un message est illustré schématiquement ci-dessous : 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Type I Length | Transaction ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Reserved I Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I I I Destination |
I Address or Prefix I i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Path Cost 1 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Lifetime 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Traffic Tag 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i . . . I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Path Cost i I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Lifetime i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Traffic Tag i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les champs « Metric I D i» représentent l'identifiant de la métrique Ί' considérée et les champs « Path Cost i » représentent le coût de la route associé à la métrique Ί', les champs « Lifetime i » représentent la durée de validité en secondes de l'information annoncée dans le message (RA) et les champs « Traffic Tag i » représentent le marquage de trafic à appliquer aux paquets de données devant être routées selon la métrique T associée. Cette information permet au nœud hôte de savoir quel marquage appliquer à ses paquets de données pour bénéficier d'un routage selon une métrique particulière. Les standards I Pv4 et I Pv6 définissent des champs dédiés au marquage des paquets. Ceux-ci se situent dans l'en-tête IP des paquets sur les champs « Differentiated Services Code Point (DSCP) » pour IPv4 et « Traffic Class » et « Flow Label » pour IPv6.
L'homme de l'art appréciera qu'une autre solution de marquage de paquets peut également être envisagée en IPv6 uniquement, celle de l'utilisation d'une extension d'en-tête IP.
La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD- ROM), Compact Disk - Read/Write (CD-R/W) and DVD).

Claims

Revendications
Dans un réseau de communication constitué d'une pluralité de routeurs (104-1 , 104-2) connectés par des liens de communication et comprenant au moins un hôte source (102) équipé de plusieurs interfaces de communication (103, 105) pour émettre et recevoir des données, chaque interface étant connectée à un routeur du réseau de communication via un lien de communication ayant un coût de lien, un procédé pour sélectionner une interface de l'hôte source pour transmettre des données à un hôte de destination (302) connecté au réseau de communication, le procédé comprenant les étapes de:
- émettre (602) depuis chaque interface de l'hôte source un message de sollicitation (RS) vers le routeur auquel ladite interface est connectée, pour demander le coût de route vers l'hôte de destination ;
- recevoir (604) sur l'interface correspondante de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée donnant une valeur du coût de route depuis ledit routeur vers l'hôte de destination ;
- calculer (614) à partir des valeurs reçues et de la valeur de coût de lien du lien correspondant, la valeur du coût de route total vers l'hôte de destination depuis l'hôte source pour chaque interface;
- comparer (616) les valeurs de coût de route total obtenues ; et
- sélectionner (610) l'interface correspondant à la valeur de coût de route total la plus basse. Le procédé selon la revendication 1 dans lequel l'étape de réception de message d'annonce de coût de route (RA) comprend une étape (606) pour vérifier si le message d'annonce (RA) reçu contient une option de coût de route, ou ignorer le message.
Le procédé selon la revendication 2 comprenant une étape initiale de sélection (2008) d'une interface par défaut pour l'hôte source.
Le procédé selon la revendication 2 comprenant avant l'étape de sélection, une étape (2002, 2004) pour déterminer le coût de lien du lien entre chaque interface de l'hôte source et le routeur auquel ladite interface est connectée.
Le procédé selon l'une quelconque des revendications 1 à 4 comprenant de plus une étape (2010, 612) pour stocker dans une table de routage de l'hôte source un identifiant de l'interface sélectionnée.
Le procédé selon la revendication 4 ou 5 dans lequel l'étape de sélection (2008) consiste à recevoir (2002) sur chaque interface de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée comprenant une valeur de coût de lien calculée selon une métrique de calcul de coût de lien définie pour ledit réseau de communication.
Le procédé selon l'une quelconque des revendications 1 à 6 dans lequel le protocole dudit réseau de communication est le protocole IPv6.
8. Le procédé selon l'une quelconque des revendications 3 à 7 dans lequel l'étape de sélection d'une interface par défaut se fait selon un protocole de découverte de voisinage (ND).
Le procédé selon l'une quelconque des revendications 1 à 8 dans lequel les liens dudit réseau de communication sont filaires et/ou sans fil.
1 0. Le procédé selon l'une quelconque des revendications 1 à 9 dans lequel le message d'annonce (RA) de coût de route contient l'adresse de l'hôte de destination.
1 1 . Le procédé selon l'une quelconque des revendications 1 à 1 0 dans lequel le coût de lien est calculé pour différentes métriques de rou- tage.
1 2. Le procédé selon la revendication 11 dans lequel le message de sollicitation (RS) contient une indication du ou des métriques pour lesquels calculer le coût de route.
1 3. Dans un réseau de communication constitué d'une pluralité de routeurs connectés par des liens de communication et comprenant au moins un hôte source équipé de plusieurs interfaces de communication pour transmettre des données, chaque interface étant con- nectée à un routeur du réseau de communication via un lien de communication ayant un coût de lien, un système pour sélectionner une interface de l'hôte source pour transmettre des données à un hôte de destination connecté au réseau de communication, le système comprenant des moyens pour mettre en œuvre les étapes du procédé selon l'une quelconque des revendications 1 à 1 2.
14. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.
EP14726086.3A 2013-05-13 2014-05-06 Procede et dispositif de selection d'interface de communication Withdrawn EP2997717A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1354267A FR3005546B1 (fr) 2013-05-13 2013-05-13 Procede et dispositif de selection d'interface de communication
PCT/EP2014/059183 WO2014184050A1 (fr) 2013-05-13 2014-05-06 Procede et dispositif de selection d'interface de communication

Publications (1)

Publication Number Publication Date
EP2997717A1 true EP2997717A1 (fr) 2016-03-23

Family

ID=49237263

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14726086.3A Withdrawn EP2997717A1 (fr) 2013-05-13 2014-05-06 Procede et dispositif de selection d'interface de communication

Country Status (6)

Country Link
US (1) US20160112300A1 (fr)
EP (1) EP2997717A1 (fr)
JP (1) JP2016524383A (fr)
CN (1) CN105247842A (fr)
FR (1) FR3005546B1 (fr)
WO (1) WO2014184050A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6265930B2 (ja) * 2015-02-23 2018-01-24 三菱電機株式会社 フレーム転送装置、リンクメトリック決定方法およびパス決定方法
US20170195218A1 (en) * 2015-12-30 2017-07-06 Qualcomm Incorporated Routing in a hybrid network
US10484263B2 (en) 2017-01-16 2019-11-19 International Business Machines Corporation Route-cost acquisition from routers
US11516723B2 (en) 2018-10-19 2022-11-29 Carrier Corporation Energy-balanced and latency-constrained routing methods in wireless network
CN113615133A (zh) 2019-03-20 2021-11-05 华为技术有限公司 一种区域间srmpls igp网络中进行最优路由的方法、节点及其系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050036486A1 (en) * 2003-08-12 2005-02-17 Zafer Sahinoglu Route discovery in ad-hoc networks with data packets
US7480248B2 (en) * 2003-08-22 2009-01-20 Samsung Electronics Co., Ltd. Apparatus and method for determining aggregated link costs in a mobile ad hoc network
JP4762735B2 (ja) * 2005-02-16 2011-08-31 株式会社エヌ・ティ・ティ・ドコモ 無線通信装置、通信経路制御装置、通信経路制御方法及び通信システム
KR101235582B1 (ko) * 2006-11-21 2013-02-21 삼성전자주식회사 무선 메쉬 네트워크에서 제어 메시지를 처리하기 위한 방법및 그 장치
US8102775B2 (en) * 2007-03-12 2012-01-24 Cisco Technology, Inc. Joining tree-based networks into an autonomous system using peer connections between the tree-based networks
US7881206B2 (en) * 2007-12-31 2011-02-01 Oracle America, Inc. Method and apparatus for mesh routing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2014184050A1 *

Also Published As

Publication number Publication date
US20160112300A1 (en) 2016-04-21
JP2016524383A (ja) 2016-08-12
FR3005546B1 (fr) 2015-05-29
CN105247842A (zh) 2016-01-13
FR3005546A1 (fr) 2014-11-14
WO2014184050A1 (fr) 2014-11-20

Similar Documents

Publication Publication Date Title
US10079803B2 (en) Peer-to-peer connection establishment using TURN
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US9674054B2 (en) Concept for providing information on a data packet association and for forwarding a data packet
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US20160044145A1 (en) Learning a mac address
FR3067550A1 (fr) Procede de communication quic via des chemins multiples
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
US20140369202A1 (en) Method, device, and system for message distribution
EP3387862A1 (fr) Dispositif et procede de communication sans-fil dans un reseau ip
EP2997717A1 (fr) Procede et dispositif de selection d'interface de communication
US20080205388A1 (en) Discovery of network devices logically located between a client and a service
EP3787344B1 (fr) Procédé de configuration d'un système d'extension de couverture de communication sans-fil et un système d'extension de couverture de communication sans-fil mettant en oeuvre ledit procédé
FR2828978A1 (fr) Procede de transmission de donnees d'un serveur d'un reseau prive virtuel a un noeud mobile
CN116489068A (zh) 路由反射对等端点的自动发现
EP2589256B1 (fr) Procédé d'établissement d'une liaison entre deux equipements de communication
EP2820872B1 (fr) Gestion de la mobilité d'un réseau mobile
EP2820873B1 (fr) Gestion de la mobilité d'un reseau mobile
FR3096530A1 (fr) Procédé de gestion d’au moins une communication d’un équipement terminal dans un réseau de communication, procédés de traitement, dispositifs, équipement terminal, équipement proxy et programmes d’ordinateur correspondants
Rothenpieler Reliability Extensions and Multi-hop Evaluation of Distributed Protocol Stacks

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151020

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

AX Request for extension of the european patent

Extension state: BA ME

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

Effective date: 20161128

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20180213

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

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

18D Application deemed to be withdrawn

Effective date: 20180626