Partition Algorithm

In LHA the “Partitioning” state of a node may be triggered by other nodes or by the node it- self. In Figure 3-24 a node may receive a New_HierID message from a neighboring node or if a node in “Searching for free address” state is unable to find a free address, as mentioned in Sec- tion 3.5.4, it sets (partition = true) which triggers the “Partitioning” state. Responding to either of these two events, the node enters the “Checking” state in which it has to check the partition threshold and update its table according to the comparison decision. Possible cases in the parti- tion algorithm are as follows:

• In “Checking” state, two actions are possible based on the comparison of the thresh-

old in “Equation (3.11)”.

o If LoA >= partition threshold, LHA supposes that there is a partitioning in the network which means that the node is able to use the addresses of the missing nodes in its partition. So it sends an AA_Conf message (positive reply) includ- ing an address of a missing address with the new HierID. Then the node enters “Updating” state.

o If LoA < partition threshold, the node knows that there is no possibility of as- signing free addresses to the new requesting node. The node, then, sends an AA_Conf message with no free address (negative reply) to the new node. Af- ter that, if there are no nodes with free addresses the node releases the “Parti- tioning” state and enters “Standby” state; otherwise, the node sends an Exist- ence Request (Ex_Req) message including a list of the nodes which have not assigned their free addresses. Then, it sets an existing node timer Tm-exist and enters the “Recovery” state which represents an address recovery algorithm, see next section for more details.

• In “Updating” state the node has to update its tables by changing the status of all

missing node into “available” and, then, it sends New Hierarchal ID (New_HierID) message to inform other nodes in the network about the new HierID by which the us- ing of lost addresses will be safe. Then it sets the change partition timer Tm-par and enters “Wait partition change” state as shown in Figure 3-24.

• During “Wait partition change” state, the node analyses any Beacon message received

from a neighboring node and defines if there is a need to resend a New_HierID mes- sage to the sender because it fails to change its HierID to the new one. In this case LHA avoids unreliable using of broadcasting messages and ensures that each node has made the required change sent in New_HierID. After the change timeout the node releases the “Partitioning” state and enters “Standby” state, which means that the par- tition algorithm has been finished.

• In “Recovery” state, LHA updates its tables on each receipt of an existence confirma-

tion (Ex_Conf) message. After the expiration of Tm-exist and before the “Partition- ing” state is released, the nodes broadcast a Mis_Node message if any corresponding

3.7 Network Partitioning Algorithms

node in Ex_Req message does not respond with the Ex_Conf message. The next sec- tion describes this case (the address recovery algorithm) in detail.

Figure 3-24: Partitioning state of LHA

3.7.3 Address Recovery Algorithm

As mentioned above, the “Partitioning” state will not be terminated if the threshold of the lost addresses is not reached and, at the same time, there are free addresses with some nodes which still exist in the configured list. LHA in this case supposes that there may be some missing nodes in the network but there is no information about them due to the failure to detect of those nodes. Therefore, the “Partitioning State” starts the address recovery algorithms to seek the existing nodes of which some or all free addresses are not allocated to other nodes. From the responses from those nodes, the partition algorithm gets accurate information about the missing nodes in the network. Because only the nodes which are expected to have free addresses are requested, LHA utilizes a multicast message which in turn reduces the signaling cost in the recovery pro- cess. The MSC chart of this case is presented in Figure 3-25. From the figure the algorithm can be described as follow:

• The node may, in the “Partitioning” state, detect in its configured list the existing of

nodes which may own free addresses. This process in LHA is possible because LHA function divides the addresses space among nodes which in turn enables each node to define the successors of other nodes in the network. After that, the node sends a mul- ticast message called the Existing Request (Ex_Req) message to the selected nodes.

• Upon receipt of this message by a corresponding node it responds by sending an Exist

Confirmation (Ex_Conf) message to the requester.

Partitioning

Checking for change

Finish Partitioning

[LoA >= partition threshold]/ AA_Conf (poistive); set (new HierID)

Wait partition change Tm_Par

Beacon [HierID == old HierID]/ New_HierID

1/ New_HierID, set (Tm_Par)

[LoA < partition threshold]&&[there are nodes with free addresses]/AA_Conf (nigative) ; Ex_Node; set (Tm_exist)

Tm_exist [no missed node] Or

Tm_exist [there are missed nodes]/ Mis_Node

Ex_Conf/ (update) [Partition==true]

New_HierID

Updating [LoA < part. thre.] &&[no

nodes with free add.]/ AA_Conf (nigative)

3.7 Network Partitioning Algorithms

• The receiving of an Ex_Conf message by the requester indicates that this node is still

connected to the network and that it has not assigned its free addresses to other nodes because of packet drops or other issues such as a temporary obstacle.

• At the end of the existing timeout, if there are some nodes with no response, the re-

questing node assumes that these nodes are missing and there is a need to inform the other nodes in the network of that. Therefore, it sends a missing node message in the network. After that it updates the information of its tables and releases the “Partition- ing” state and enters the “Standby” state.

• When other nodes in the network receive a Mis_Node message they update their tables

according to the new information.

This mechanism to detect the missing nodes is not the only one in LHA because it starts only when there is a need to assign free addresses. In the departing algorithm, LHA uses another method to detect the missing nodes, for details see Section 3.8.

Figure 3-25: Search for nodes X and Y which own free addresses wherein node Y is no more in the network

3.7.4 Special Case (Stand Alone Node)

A special case of a partition scenario is that when a single node is not able to connect other nodes in the network, for example because of an obstacle. The solutions in much of the literature usually consider this case as an abrupt departure. The solving of this case as departing node may, however, cause address conflicts in the network because the node may reconnect to the network when the obstacle vanishes.

The LHA protocol defines an “Alone Standing” state in which this problem is well defined and solved as shown in Figure 3-26. The basic idea in LHA to solve this case is to change the

Ex_Conf Ex_Req

Tm-exist Node A (with no

free addresses) Recovery requester

Mis_Node Mis_Node Partitioning Forwards to X & Y No response from Y (Announcement of missing) Standby Standby Node B (with no

free addresses) free addresses)Node X (with

Ex_Req Ex_Conf

Standby

Detect nodes (X and Y) have free addresses

3.7 Network Partitioning Algorithms

configuration of this node to a temporal or preserved one in which a node is not able to assign addresses form the original network configuration to a requesting nodes. There follows a detailed description of the state machine in the figure.

Figure 3-26: State machine of a node with alone standing state

The “Alone Standing” state is triggered when a node in “Standby” state (see Figure 3-13) de- tects an event that a node is standing alone. LHA generates this event when the standalone timer expires without receiving any Beacon message from neighboring nodes. This means that during the Tm-alone timeout the node has failed to detect any Beacon from its neighbors. So in this case the node concludes that it stands alone (Alone=true). Thus, in the “Alone Standing” state the node behaves as follows:

• In “Change MN and save old configuration” the node has to change its MN to a pre-

served one or 0, and to keep a track of its configuration (saving its original configura- tion). Then, it enters “Wait for rejoining” state.

• In “Wait for rejoining” state the node works in a normal way by sending regular Bea-

con message including the new MN. During this state the new node may receive one of two messages; Beacon from another configured node or AA_Sol message from a new node.

o If the node receives a Beacon message from another node it has to do the fol- lowing:

 If the parameters in the received Beacon are equal to the old ones (Hie-

rID, Root, Hash and MN) then it reuses its old configuration. Then it sends an Info_Req message with empty configuration and its lists. Af- ter that, it enters “Wait Info” state.

Alone Standing

Wait info

Beacon [belong to my old network]/ Info_Req, set (Tm_Info) Change MN and save old

configuration 1/ Beacon, Set (Tm_Bec)

Wait for rejoining

Beacon [doesn't belong to my old network]/ set (Release = True)

Tm_Info

Info_Rep/ (retrun to old configuration), New_Node, set (Release= false) 1/ AA_Rep(free) ,

set (Release= false), (allocate seq(i) for requester)

Build new address hierarchy

AA_Sol