Patent Application
20110317710
This application claims priority to foreign French patent application No. FR 09 06215, filed on Dec. 21, 2009, the disclosure of which is incorporated by reference in its entirety.
The subject of the invention relates to a method of dynamic routing or routing protocol used in the field of low throughput networks operating in the 30 MHz-600 MHz bracket. The method according to the invention is used, for example, on nodes interconnecting several different physical networks, some of which are low throughput and high latency, such as VHF (Very High Frequency) radio networks. The protocol according to the invention or method of routing may be used in any UHF, VHF or other transmission network.
In the technical field of communication networks, one of the problems which arises is to find mechanisms for exchanges between routers which are at one and the same time reactive and economical as regards bandwidth used. The difficulty consists in fact in rapidly establishing the topology of the routers, both in the setup phase and in the phase of modifying the components of the network (disappearance, appearance of routers, change of network hookup of the routers), while not flooding the networks with protocol exchanges which may consume a significant part of the available bandwidth.
The state of the art known by the Applicant in this regard relates notably to routing protocols used on the Internet protocol (IP for short) which are defined for example in the RFCs (Requests for Comment) which are a set of documents which make reference to the Internet Community and which describe, specify, aid the implementation, standardize and debate the majority of the standards, norms, technologies and protocols related to the Internet and to networks in general. Among these documents may be cited the experimental protocols defined within the framework of the working groups on mobile networks or Mobile Ad Hoc Networks known to specialists in the Field, or else the standard protocols used for interconnections of wire-based networks.
Despite the effectiveness of these protocols, the tactical-network interconnection topologies currently known in the military field exhibit notably the drawback of exhibiting redundancy of the nodes between networks and of networks between nodes, thereby generating an increase in protocol exchanges.
In the case of low throughput networks (from 1 Kbit/s to a few tens of Kbits/s), the existing protocols known to the person skilled in the art are not designed to optimize the reduction in the quantity of protocol information exchanged, necessary for correct operation of low throughput networks. These protocols in general therefore saturate the bandwidth of VHF radio networks and to a lesser extent that of UHF networks. Likewise, the disregard of the concepts of parallel or redundant networks between nodes gives rise to avalanche phenomena in certain protocols, thereby causing significant traffic.
The protocols mentioned hereinabove do not therefore make it possible to achieve economy of bandwidth. Moreover, the risk of a high rate of losses of potential packets is disregarded by the existing protocols. These protocols do not therefore make it possible to obtain fast convergence while exchanging a small quantity of information.
Patent application WO 2008/055539 discloses a multi-domain network in which each domain of the network collects intra-domain routing information and generates a reduced view of this information available to the other domains of the network.
The following definitions will be used herein:
The routing protocol according to the invention includes at least four principles:
These principles will be explained further on in the description. The word method or the expression “FIRE protocol”, or else “protocol”, will be used to designate one and the same object, namely the method of enhanced reliability routing according to the invention.
The invention relates to a method of enhanced reliability routing within a system comprising one or more networks composed of several nodes connected together by communication means, the said system comprising a transmission network access or TNA charged with transmitting on a physical medium the data to a next network interconnection node NIN, the said system using a link-state routing protocol constructing the topology of the nodes within a system of nodes, characterized in that the said routing method determines the logical topology of network interconnection nodes NIN used in combination the following modules:
Other characteristics and advantages of the invention will become more readily apparent by reading the following detailed description given by way of nonlimiting illustration, together with the figures, in which:
In the following detailed description of exemplary embodiments of a dynamic method of enhanced reliability routing according to the invention, the following apply:
The routes depending on numerous criteria (HYP_TOPO—1), there exists a very large number of possible routes, each being the ‘best’ for a packet having given characteristics. The solution adopted for the protocol according to the invention is to use a link-state routing protocol, which constructs the topology of the nodes; the best route for the data packets being calculated thereafter locally on each of the nodes.
The method according to the invention or FIRE will calculate the logical topology of the NIN nodes within a system of NIN nodes. In this logical topology of the NIN nodes, two NIN nodes A and B are connected together directly, if there exists an elementary network to which node A and node B belong, independently of the number of physical hops between A and B within the elementary network.
This topology must have the following characteristics (HYP_TOPO_2):
These characteristics will be used as routing criteria.
Principles of a link-state protocol
So-called “link-state” protocols make it possible to establish a topology of routers (or NINs, according to the terminology employed), each router running an instance of the protocol. The operation of the inter-network routing protocols with state of links can amount to the following main mechanisms:
These main mechanisms are supplemented with the secondary mechanisms, whose objective is that of:
The definition and the settings of the main and secondary mechanisms is done so as to optimize two contradictory criteria:
C1: the bandwidth consumed by the exchanges of the routing protocol,
While also complying with a 3rd criterion:
One of the objectives of the protocol is to have high reactivity with low consumed bandwidth. This may be represented by a high ratio C2/C1, while complying with C3.
List of the main mechanisms of the enhanced reliability radio topology function (FIRE) implemented in a method according to the invention
The following paragraphs will exhibit the mechanisms adopted for the function for establishing the topology of the NINs. They are identified by a prefix ‘FIRE_’ followed by a 2-digit index (e.g.: FIRE_04). The requirements on a mechanism are denoted by FIRE_XX/YYY where YYY is the requirement index, customarily incremented from 10 in 10 s, this merely being a nonlimiting example.
These mechanisms are 9 in number:
The mechanisms interact according to the mechanisms described in
Module 11 NIN_TOP_01: Discovery of the Neighbourhood by virtue of the intrinsic functions of the physical networks
The transmission module or “FORWARDER” of an NIN node interconnects physical networks. The technologies of these physical networks being very different in nature (throughput, lags, losses, etc.), the FORWARDER relies on the transmission networks to calculate its neighbourhood information, which explains the requirement hereinafter.
Each access to a Transmission Network TNA of the NIN node must provide the protocol according to the invention with the topology of the elementary network of which it forms part. This topology must contain the description of a graph of nodes having the following properties:
The NIN address to connection address resolution function and the reciprocal function being ensured by the TNA, the topology provided contains addresses of NIN nodes and not connection addresses (specific to the transmission network). A node of the graph of the elementary network has no NIN address when this node represents a transmission relay with no node function.
NIN_TOP_01/010 suffices to ascertain the neighbour NINs (in the logical sense) and the number of physical hops within the transmission network between 2 NINs. However, a further item of information is desirable for correctly estimating the quality of the network connection between 2 NINs.
When the TNA provides an elementary network topology to FIRE, it must provide, if the technology of the transmission network so allows, the following complementary information:
Module 12: NIN_TOPO_02
To economize on the bandwidth consumed by the inter-NIN topology signalling on radio transmission networks, the dispatches of signalling data cannot be too frequent. In fact, it is not desirable (nor even beneficial) to announce to the other NINs ‘in real time’ the changes of the characteristics of the links or of internal topology that are provided by a TNA.
The information provided by the TNAs must therefore be processed before being passed on to the other nodes, so as to ensure a certain stability of the information dispatched and of the resulting topology.
The first processing relates to the characteristics of the links between nodes:
According to the dynamic characteristics of the transmission networks, the protocol according to the invention FIRE must smooth certain variations of the characteristics of the links before including them in the neighbourhood broadcast to the other nodes.
The second processing relates to the internal topology of the networks:
To manage the meshed networks and smooth the evolution of their topology, the protocol according to the invention will rank the numbers of hops into 3 categories (close, medium, distant) with a hysteresis to enter and exit each category as a function of the number of real hops. This categorization depends on the type of service to be made to transit through the transmission network. Finally, so that the neighbourhoods can be dispatched to the neighbour NINs “nominatively”, FIRE must update and provide the 1-hop topology to the FORWARDER.
On receipt of a topology of an elementary network, and once the smoothing operation has been performed (NIN_TOPO_02/020), the method according to the invention will save the smoothed topology in a Local_Topology_Table table, 20
When Local_Topologies_Table is modified, then the function for constructing the graph recalculates the graph and thereafter updates the topology of the NINs.
So that each NIN can construct the complete topology of the network, it is necessary and sufficient to ascertain the set of neighbours of each NIN and the characteristics of the links between each NIN and its neighbours. The basic principle is therefore that each NIN announces to all the other NINs these data (neighbours, links and their characteristics), which will be dubbed Sig_Neighbourhood.
To optimize this broadcast:
On each new elementary network topology received, the protocol according to the invention FIRE must construct the set of the following elements, called Sig_Neighbourhood:
The unscheduled properties of the local NIN node, if such exists (transit capacity, services that can be relayed, etc.)
The identification of the transmission network of which RE forms part (i.e through which the neighbour NIN is accessible, there exists a global identification of each transmission network:
Thereafter if first_new_topology=TRUE then FIRE must set max_waiting_for_new_network_topology_timer (on starting FIRE, first_new_topology must be initialized to TRUE). This timer corresponds to the maximum waiting time for new topologies of elementary networks originating from the TNAs, once the first topology has been received; its objective is to avoid the transmission of too many Sig_Neighbourhoods during the instability phases.
Next the FIRE protocol must reset the timer waiting_for_new_network_topology_timer. This timer corresponds to the waiting time for a new topology of an elementary network; being systematically reset, it is the timer max_waiting_for_new_network_topology_timer which avoids a perpetual wait; and finally
The FIRE protocol must toggle first_new_topology to FALSE. This state variable is used to launch the timer max_waiting_for_new_network_topology_timer only on receipt of the first new topology of a “burst”.
For example, a VHF or UHF radio network is intrinsically identified by the parameters which allow its members to communicate (keys, frequency, etc.). The grouping of these parameters into a short unique identifier (1 to 2 bytes) makes it possible to broadcast the intrinsic properties of the network, while consuming less bandwidth than if the exhaustive list of the values of its parameters were broadcast. On the other hand, the membership of the NINs in a network is broadcast and not known by scheduling. It is not used to deduce connectivity information therefrom but for information regarding characterizations of the links (used for multi-criterion routing). In fact, splitting the transmission networks into several elementary networks has no impact on the operation of the routing protocol.
The objective of the timers present in NIN_TOPO_010 is to avoid transmitting information immediately after indication of a new topology of a transmission network. It is particularly useful during the phases of startup, of arrival in a new network, etc. when the topologies of transmission networks change rapidly. After receipt of a change of topology following a stable state, at the maximum at the end of the global timer max_waiting_for_new _network— topology_timer, the Sig_Neighbourhood is dispatched.
The CRC contained in a Sig_Neighbourhood allows the neighbours receiving the latter to verify that the reconstruction of the Sig_Neighbourhood complies with the initial Sig_Neighbourhood.
On expiry of max_waiting_for_new_network_topology_timer or of waiting_for_new_network_topology_timer, the FIRE protocol must provide Sig_Neighbourhood to the Sig_Neighbourhood_Transmitted construction function defined by NIN_TOPO_03/030, and set first_new_topology to TRUE. The requirement NIN_TOPO_03/010 constructs the whole of the neighbourhood of a node N, independently of the recipient neighbour. Now, for a given neighbour Ni, this neighbourhood contains information that Ni already knows, such as the links N<->Ni. To avoid transmitting information that is non-relevant on the networks, FIRE calculates for each neighbour Ni a lightened Sig_Neighbourhood, denoted by Sig_Neighbourhood_Transmitted[Ni].
When the FIRE protocol dispatches a local Sig_Neighbourhood (module 13a
FIRE must thereafter dispatch these Sig_Neighbourhood_Transmitted[Ni] according to the requirement NIN_TOPO_06/010 described hereinafter.
These processings make it possible to decrease the size of Sig_Neighbourhood transmitted to each neighbour. As the sequence index is known only to the local node, it must necessarily be dispatched. At the minimum, a Sig_Neighbourhood_Transmitted[Ni] is reduced to the sequence index. It should be noted that Sig_Neighbourhood_Transmitted is generally different according to the neighbour to which Sig_Neighbourhood ought to be dispatched.
For example, for a set of nodes connected solely to a single elementary network RE, each node not having any dynamic characteristics: Sig_Neighbourhood amounts to the sequence index and to the information uploaded by the TNA of RE, and Sig_Neighbourhood_Transmitted comprises solely the sequence index (known solely to the sender) and the value of the CRC (calculated on the initial information, and which allows the receiver to ensure that the reconstitution that it does complies with the origin).
This optimization makes it possible to drastically decrease the quantity of protocol traffic in the case of the redundant inter-NIN links, which may be created either by redundant networks between nodes, or by redundant nodes between networks.
Option making it possible not to dispatch some Sig_Neighbourhood_Transmitted,
As long as the Sig_Neighbourhood_Transmitted amounts to the pair (sequence index, CRC), it is not compulsory to dispatch it (i.e. if no Sig_Neighbourhood_Transmitted has ever been dispatched previously). It is obvious that the neighbour not receiving any Sig_Neighbourhood, it will not be able to relay anything even if it is RSN for us.
The reconstituted topology is incomplete, since it lacks the links contained in the Sig_Neighbourhood_Transmitted which have never been transmitted. However these ‘non-transmitted’ links are of only local interest. The remote nodes, which will have an incomplete topology, do not need these links to calculate the best route whatever criteria are adopted.
For example, let us assume that an elementary network RE1 comprises 4 nodes (1, 2, 3 and 4), all in range of one another. This elementary network is connected to other networks via node 4 and by it alone. Nodes 1, 2 and 3 do not then transmit any Sig_Neighbourhood_Transmitted. Node 4 transmits to the other nodes (5 and plus) its links with 1, 2 and 3: (1, 4), (2, 4), (3, 4). Nodes 5+ will therefore never know of the existence of the links (1, 2), (1, 3), (2, 3). However, to reach 1, 2 or 3, a node 5+ will pass through 4 and will therefore never need these links.
In the example given, only the logical links are considered, the physical topology of the network RE1 not being considered: thus, it is entirely possible for the physical path between 4 and 1 to pass through 2. Physically, the topology corresponds to (4->2->1), but logically, from the “inter elementary network” point of view, the topology is (4->1).
NIN_TOPO_03/040
When the FIRE protocol receives a Sig_Neighbourhood (N), and N is not a neighbour of the local node, it must store the Sig_Neighbourhood received in the Distant_Neighbourhood_Table table.
When FIRE receives a Sig_Neighbourhood (N), and N is a neighbour of the local node (=>Sig_Neighbourhood received is in fact a Sig_Neighbourhood_Transmitted):
FIRE must reconstitute the Sig_Neighbourhood(N) on the basis of the Sig_Neighbourhood_Transmitted received and of the topologies of the elementary networks.
Thereafter, FIRE must calculate the value of the CRC on the Sig_Neighbourhood reconstituted.
If this CRC is different from the CRC contained in the Sig_Neighbourhood_Transmitted,
The reconstruction of the Sig_Neighbourhoods as soon as the Sig_Neighbourhoods_Transmitted are received allows the core of FIRE to manipulate only complete Sig_Neighbourhoods.
When the CRC of a Sig_Neighbourhood(A) reconstructed by a node B does not correspond to the initial Sig_Neighbourhood(A), there is an inconsistency between the network topologies provided by the TNAs to node A and those provided to node B. For a given network, two cases can lead to this inconsistency:
With each receipt of a new elementary network topology originating from a TNA, FIRE must, for each Sig_Neighbourhood_Transmitted present in the Neighbourhood_Rebuilding_Table table:
The Sig_Neighbourhoods sent by each node must be forwarded to all the NINs, so that each NIN can calculate the topology of the network. They must therefore be relayed. To limit the number of superfluous relayings (i.e. 2 stations relay the same neighbourhood to the same recipients), only a subset of NIN relays the Sig_Neighbourhood. These NINs are called Relays of Sig_Neighbourhood (RSNs for short).
The election of the RSNs is done by auto-designation, which has the advantage of not necessitating any additional exchanges on the networks.
The objective of the mechanism for electing the RSNs is to calculate a distribution graph (DG):
Such a distribution graph DG is a sub-graph of OG such that, whatever a source belonging to the origin graph OG, an item of information sent by this source can be distributed to all the other nodes of OG while being relayed solely by nodes of DG.
Remarks on the optimization of the distribution graph:
Having regard to the previous remarks and to the difficulty in designing a distribution graph construction mechanism which is aimed at an uncertain optimality, the approach adopted has been to simplify its design. The mechanism adopted for the election of the RSNs has therefore been formulated as a function of the following:
In tandem with the discovery of the complete topology, it might be tempting to refine the graph of the RSNs. However, this would necessitate on the one hand complementary inter-NIN exchanges on the networks, and on the other hand the Sig_Neighbourhoods being relayed only once and in enhanced reliability mode, the change of status from RSN to non-RSN could culminate in inconsistencies of distribution.
To construct the graph of the RSNs, we start from the intrinsic property of a Relay of Sig_Neighbourhood: A Relay of Sig_Neighbourhood makes it possible to make a connection between two nodes which are not directly in sight of one another.
Therefore, in order for a node to be RSN, it must know that two of its neighbours are not in sight of one another. The reception of the Sig_Neighbourhoods of its neighbours suffices to establish this knowledge, as shown by the examples hereinbelow in relation to
A node N is potential RSN for a pair of nodes (A, B), no. (A)<no. (B), if and only if all the following conditions are fulfilled:
For a given pair, it is always the neighbourhood of the smallest node index which is analysed. In the case of consistent neighbourhoods, if A is B's neighbour, B is then A's neighbour (the logical links contained in the neighbourhoods are symmetric). In the case of inconsistent neighbourhoods, as only a single neighbourhood is analysed, there is no case of inconsistency to be processed in the algorithm.
Not all the potentially RSN nodes are systematically elected RSN: if two potentially RSN nodes are equivalent (i.e. relay between the same neighbours, like nodes 2 and 4 in the diagram hereinabove), it suffices to keep just one of them to construct the distribution graph.
By definition, a potentially RSN node N2 equivalent to another node N1, for a given pair of neighbours (VA, VB), is both VA's neighbour and VB's neighbour. It is therefore present in the Sig_Neighbourhoods of VA and VB, received by N1. The common nodes between VA and VB (with A and B not mutual neighbours) are therefore the potential RSNs for A and B. By analysis of the neighbourhoods, each potential RSN node can therefore find the other potential RSN nodes.
Consider a pair of neighbours (A, B).
Let nc(i) be the number of pairs of neighbours relayed by each node i which is a potential RSN of (A, B), the pairs taken into account having to be detectable by all the other nodes that are potential RSNs of (A, B).
Let max_nc be the maximum of the nc(i), calculated over the set of potential RSNs of (A, B).
FIRE must be elected RSN for a pair of neighbours (A, B) if and only if: it is a potential RSN for the pair (A, B),
and if it complies with one of the following three conditions:
FIRE must save the list of pairs (A, B) of which it is RSN in the RSN— Status— table, 23
The Sig_Neighbourhoods of the neighbours may not be received:
In this case, according to the previously described algorithm for electing the RSNs, an NIN which does not receive a Sig_Neighbourhood of a neighbour may not be elected potential RSN and still less RSN. To make up for this deficiency, an NIN can also be auto-elected RSN, according to the mechanism hereinbelow, described in NIN_TOPO_04/030.
On modification of Local_Topologies_Table, in the case of the appearance of new neighbour nodes (i.e. nodes which did not exist in the previous Local_Topologies_Table), FIRE must perform the processings described in the remainder of the requirement.
FIRE must trigger the timer RSN_waiting_neighbourhood_timer.
If RSN_first_topology=TRUE, then FIRE must trigger the timer MAX_RSN_waiting_neighbourhood_timer and thereafter toggle RSN_first_topology to FALSE.
If FIRE receives at least one Sig_Neighbourhood of each new neighbour before expiry of one of the 2 timers, then it calculates its RSN status according to the requirements NIN_TOPO_04/010 and NIN_TOPO_04/020.
Otherwise (expiry of one of the two timers):
FIRE must save the list of pairs (A, B) of which it is RSN in the RSN— Status— table.
On modification of Local_Topologies_Table not processed by NIN_TOPO_04/030, in the case of disappearance of neighbour nodes, then FIRE must calculate its RSN status according to the requirements NIN_TOPO_04/010 and NIN_TOPO_04/020.
On modification of Distant_Neighbourhood_Table relating to at least one Sig_Neighbourhood of a neighbour, then FIRE must calculate its RSN status according to the requirements NIN_TOPO_04/010 and NIN_TOPO_04/020. Algorithm for electing the Relays of Sig_Neighbourhood
Let a be the local node, i.e. that on which the algorithm is executed.
Let Va be the set of neighbour nodes of a. Va is the local neighbourhood, calculated on the basis of the information provided by the TNAs.
Let Wa, i be the set of neighbours of a node i∈Va. Wa, i is the set of nodes contained in the Sig_Neighbourhood of i. If no Sig_Neighbourhood is received, Wa, i={a}.
Let L be the set of nodes of the local topology which consists of the local node, of the neighbour nodes and of the neighbour nodes within two hops.
L=Va∪Wa,i/i∈Va
The first step includes constructing, for each node n∈L, the known set of neighbour nodes of n, Vn.
If n∈Va, Vn=Wa,n by definition.
If n∉Va, Vn={nodes i, such that n∈Wa,i}
The second step includes establishing, for each node n, the set of pairs (i, j) such that i and j are neighbours of n, but are not mutual neighbours. This set is denoted by Cn.
Let n∈L. We then have Cn={(i, j) with i and j belonging to Vn, such that i≠j, i∉Vj, and j∉Vi }
Denoting by C, the union of the values Cn, for all the nodes of L:
C contains the set of pairs of nodes of the local topology L which are neighbours within 2 hops without being mutual neighbours.
By construction, Cn is the set of pairs for which n is potential RSN.
The third step includes determining, for each pair c of nodes that are 2 hops apart and not mutual neighbours, the set of potential RSNs of the pair c, denoted Rc.
By definition, the pairs to be considered are the elements of C.
Let c E C. By definition of the Cn and of Rc, we have: Rc={nodes n, s.t. c ∈Cn}.
Let us denote by R, the union of the values Rc, for all the pairs c of C:
The fourth step includes determining the set of pairs for which the local node (node a) is relay.
Assignment of a weight to each potential RSN.
For each node n∈L:
The weight function presented hereinabove is merely an example. The algorithm may be adapted with the aid of other weight functions, as long as they meet the following criterion:
An example of such a weight function: p(n)=n.
Calculation of the pairs for which the local node is relay
The set of pairs for which the local node ‘a’ is RSN consists of the pairs ‘c’ such that ‘a’ is potential relay of ‘c’ (a∈Rc) and that the weight of ‘a’ is the highest with respect to the weights of the other potential relay nodes of the pair ‘c’. In the case of equality of weight with other potential relays, ‘a’ is RSN of ‘c’ if and only if ‘a’ possesses the smallest node index among the set of potential relays of ‘c’ of maximum weight.
Let C_RSN(a) be the set of pairs for which ‘a’ is RSN. C_RSN(a) is calculated in the following manner:
The set of pairs for which the local node is relay is thus obtained.
The RSNs relay the Sig_Neighbourhoods gradually until all the nodes of the system have the same neighbourhood database. The enhancement of reliability of this forwarding is done by the RSNs (cf. NIN_TOPO—05, module 15), and not by repetitions performed by the origin node of the Sig_Neighbourhood. This implies that once an NIN has generated its Sig_Neighbourhood and has transmitted it successfully to its neighbours, it no longer retransmits it. Its next transmission will take place when the content of the Sig_Neighbourhood has changed.
This principle has two major consequences:
A Relay of Sig_Neighbourhood is therefore in charge:
of storing them to ensure the synchronization of the tables of Sig_Neighbourhoods of these same neighbours, when necessary.
An NIN A, RSN for pairs (Xi, Yi), relays every Sig_Neighbourhood received from Xi to the node Yi (and vice versa from Yi to Xi), except if:
The above conditions make it possible to avoid unnecessary dispatches. They require the RSNs to store the Sig_Neighbourhoods received and the index of NIN neighbours that dispatched this Sig_Neighbourhood to them.
When an NIN A (again) becomes RSN for a pair (X,Y), it must relay to Y all the stored Sig_Neighbourhoods that it has received from X (and vice versa), except if:
The receipt of sequence indices that are older than the sequence index stored is dealt with in the paragraph NIN_TOPO_08.
It should be noted that in the requirement NIN_TOPO_04/060, it is not specified if A was already RSN for another pair. The two cases (‘A was already RSN’, ‘A was non-RSN’) are possible. If A was non-RSN, it must nevertheless be able to comply with this requirement, and therefore have stored all the Sig_Neighbourhoods received, and have noted which neighbour has sent or relayed each Sig_Neighbourhood to it.
For each Sig_Neighbourhood received, FIRE must verify whether there exists a Sig_Neighbourhood of the same origin node and of identical or more recent sequence index.
If so, then FIRE must delete the Sig_Neighbourhood received.
Otherwise FIRE must store, in a table called Distant_Neighbourhood_Table:
One and the same node can appear several times in the content of the Sig_Neighbourhood if the origin node can reach it through several transmission networks.
The sequence index of the Sig_Neighbourhood stored is the most recent sequence index present in the list LPHR.
Each NIN must store, in the Distant_Neighbourhood_Table table, an exemplary format of which is given in
the list of neighbour NINs to which the local node has relayed a Sig_Neighbourhood(NIN_origin) and which have acknowledged positively. This list is denoted by LANH (List of Acknowledged Next Hops).
Subsequent to a re-calculation of the local neighbourhood or of the topology, FIRE must preserve in the table of distant Sig_Neighbourhoods, an example of which is given in
This preservation makes it possible to limit the exchanges of Sig_Neighbourhood in the case of reconnection of 2 parts of the system.
There is never deletion of an origin node, since there is no mechanism of aging in the normal operation of the protocol.
The impact of Radio Silence is as follows:
When FIRE transmits a Sig_Neighbourhood to neighbour NINs, it must ask the underlying layers used, to dispatch the Sig_Neighbourhood in enhanced reliability mode.
The hop by hop enhancement of reliability function is preferably situated in the TNAs, since it depends on the intrinsic properties of the medium (use of TCP on a unicast IP network, PMUL on a VHF network, etc.).
When FIRE transmits a Sig_Neighbourhood to neighbour NINs, it must if possible ask the underlying layers used, to dispatch the Sig_Neighbourhood in point-to-multipoint mode.
The Forwarder then duplicates the Sig_Neighbourhood if it must be sent on various elementary networks. Thereafter, each TNA decides to undertake one or more dispatches, with an adapted enhancement of reliability (cf. NIN_TOPO_05), according to the type and the nature of the underlying network (point-to-point or broadcast, reliable or with significant losses, etc.).
There exist characteristics of links which depend on the direction of the link. The throughput of a radio connection between A and B may be different from the connection between B and A. At the level of node A, the topology uploaded by a TNA may contain both the throughput from A to B and from B to A.
If A and B each announce in their Sig_Neighbourhood both throughputs:
When a FIRE transmits the Sig_Neighbourhood from the local NIN to neighbour NINs, it must remove any item of information which depends on the orientation of the links and which relates to the oriented links of which it is destination (i.e. of which it is not the source).
Module 18 NIN_TOPO_08: Marking of the signalling data so as to manage non-sequencing in reception
The Sig_Neighbourhoods are stamped with a sequence index, chosen by the source of this Sig_Neighbourhood.
When FIRE transmits the Sig_Neighbourhood from the local NIN to neighbour NINs, it must include therein a sequence index making it possible to detect the reboots of the nodes and the desequencings introduced by the network transmission.
When the machines on which FIRE is installed are synchronized (to within a few seconds), FIRE must use a date as value of sequence index.
Module 19 NIN_TOPO_09 Calculation of the global topology
Principles for constructing the global topology.
On the basis of all the Sig_Neighbourhoods received, each NIN constructs the graph of the topology starting from itself, and then of its neighbours, etc., taking into account only the information provided by the analysed node: when the Sig_Neighbourhood of a node A is analysed, oriented links starting from A are traced to all the NINs declared in this Sig_Neighbourhood as neighbours of A. We will call this principle of graph construction “oriented construction”.
The principle of oriented construction makes it possible to manage the absence of any idea of aging of the Sig_Neighbourhoods. Conventionally, to manage the disappearance of a node (fault, destruction or simply temporary non-accessibility), the link-state protocols consider that the non-receipt of a neighbourhood of this node for a certain duration signifies that it is necessary to delete the neighbourhood information of this link. This is based on the fact that they regularly repeat the neighbourhoods. As FIRE, to economize on band and render the enhancement of reliability of the exchanges more suited to the networks, does not repeat the neighbourhoods but enhances reliability hop by hop, this aging mechanism may not operate.
The principle underlying oriented construction is as follows: when a node A disappears, its neighbours are aware of this. The neighbours “closest” to us (e.g.: B) will therefore announce to us (indirectly, by their new neighbourhood) the disappearance of their link with node A. Even if we preserve the Sig_Neighbourhood of A (which can remain true or false, we cannot know), the link between A and B becomes oriented solely from A to B, and no longer from B to A. A then becomes inaccessible to us from B.
Let ‘a’ be the local node.
Let NAT be the set of nodes to be processed, i.e. the nodes for which it is necessary to analyse the Sig_Neighbourhood so as to add links to the topology graph. Initially, NAT={a}.
Let NDT be the set of already processed nodes, i.e. the nodes whose Sig_Neighbourhood has already been taken into account. Initially, NDT=.
Let G be the global topology graph, represented in the form of a set of links, each link being a triple, consisting of the 2 end nodes of the link and of the transmission network traversed. Initially, G=.
As long as NAT≠, carry out the following processing:
The method according to the invention presents notably the advantages listed hereinafter: the FIRE protocol is based on four major principles:
The recovery of the media topologies,
Enhanced reliability broadcasting,
Management of recipient nodes and not of output interfaces,
Relevant sending of information (No sending of information known by the neighbour nodes.)
The transmission network (UHF, VHF, etc.) uploads the local topology to the nodes. Each node takes cognizance of its local topology without FIRE sending the least packet, thus saving network bandwidth.
The topology information exchanged between the nodes is broadcast in a reliable manner, by virtue of the following mechanisms.
Each node, on the basis of its local topology uploaded by the transport network (P1), and of the neighbourhood of its neighbours, establishes a finite and deterministic subset of pairs of nodes for which it will be relay of neighbourhoods (RSN). This auto-election is by local construction and does not require any additional transmission on the part of FIRE.
Thus, for example, if a node A is auto-elected neighbourhood relay (RSN) for the pair of neighbour nodes (B, C), any neighbourhood message sent by B (and respectively by C) will be retransmitted by A to C (respectively to B).
Broadcasting is therefore by construction greatly limited with respect to a conventional broadcast by flooding.
The enhancement of reliability of the neighbourhood messages is for its part performed by acknowledgement. This acknowledgement may be performed by the network forwarding function or by the medium layer.
In contrast to many protocols described in the literature, FIRE is based on an approach for managing the recipient nodes, and not output interfaces.
The topology information is sent to a node in particular and not over a network. This makes it possible, in the case of parallel networks, to use just one of the networks to send the neighbourhood signalling packet to this same node, thus limiting the bandwidth consumed. The choice of this network (the fastest, the most robust, that covering the most recipient nodes) is left to the network forwarding function.
Based on principle P3, when two nodes A and B are neighbours in the topological sense of the term (P1), it is not necessary for A (respectively B) to transmit common information to B (respectively A). Only the additional, and therefore relevant, information is transmitted.
This affords the method according to the invention at least the following advantages:
| Number | Date | Country | Kind |
|---|---|---|---|
| FR0906215 | Dec 2009 | FR | national |
