Inter-cluster Scenarios

4.2.1. Virtual IPv6 Wireless Mesh Network Topology

The virtual testbed in this second phase is composed of two cluster controlled by CH1 and CH2, two routers AR1 and AR2 and a Relay router.

The virtual testbed is illustrated as in Figure 42. There are two MNs which don’t have any specific software to support the mobility. Initially, MN1 is attached to AR1 and MN2 is attached to AR2. IEEE 802.11 is used for the virtual wireless link. The Relay interconnects the two clusters by means of routes to CH1 and CH2. Each AR has two interfaces; one is connected to the CH, egress interface, while the other one is connected to the MNs, ingress interface. Each MN has one interface by which it attaches to the AR. We assume here that there is no IPv6 address conflict and therefore use a shared-prefix model with a shared prefix of 2001:1::/64 for the wireless access link.

- 95 -

Figure 42. Virtual Testbed for Inter-cluster Communication

4.2.2. Scenario 1: Inter-cluster Communication

Description. This scenario aims at testing if the data can be properly routed between MN1 and MN2 belonging to different clusters. The creation of three bi-directional tunnels: between AR1 and CH1, between AR2 and CH2, and between CH1 and CH2 along with the associated routes and rules will be verified to be operational. In this scenario, MN1, which is attached to AR1, tries to ping6 MN2, which is attached to AR2. Hence, MN1 sends an Echo Request to MN2 and should receive an Echo Reply message.

As a shared prefix is used, the NS message is sent by MN1 to find the MAC address for the destination, which is MN2 in this case. AR1 captures the NS message, parses it and detects that the target is not under the control of AR1; therefore, it starts the PBReq messages chain to locate the serving entities of the target MN2. At the end of the process, a bidirectional tunnel is established between CH1 and CH2, and AR1 learns that the serving entities of MN2 are CH2 and AR2. AR1 then replies the NS message to the MN1 with its own link layer address so MN1 starts transmitting the Echo Request messages using the MAC address of AR1.

Upon reception of the packet on AR1, it will check the source and by the rule previously created, it will direct the routing process into the PMIP routing table, which includes a default route that forwards all traffic via the tunnel to CH1. Here, the outer IP header’s source address is the AR1 address and the destination address is the CH1 address. The inner header’s source address is the MN1 address and the destination address is the MN2 address as the packet is destined for MN2.

Therefore the packets are encapsulated using IP-in-IP encapsulation and de-tunneled at CH1, which will further route the packets based on its destination address.

Since no rules are added for source based routing, and consequently the traffic will be forwarded into the tunnel interface previously created with the serving CH2 of the

- 96 -

MN2. The outer header’s source address is CH1 and the destination address is CH2.

The inner header source address is MN1 and the destination address is MN2. The packet is encapsulated here and it is sent to CH2.

Once it reaches CH2, the packet is decapsulated and it is destined to MN2 as in the intra-communication case. Once MN2 receives an Echo Request message, it replies back to MN1 with an Echo Reply message with a link-layer MAC address of AR2 found in the NA message, which is sent by AR2 based on the ARP request issued previously by MN2 to ask for the MAC address of MN1. The message takes a path in a similar fashion to the previous one, which is proceeded from MN2 as the source and MN1 as the final destination.

As the Echo Reply reaches AR2, it passes through the tunnel. Like before, once CH2 receives the packet, it decapsulates the packet, and looks for the route based on destination address. Again, the packets pass through tunnel that links CH2 to the serving CH1 which in turn de-tunnels the packets and re-tunnel them to AR1. Here the packets are decapsulated and forwarded to MN1 through the wireless access link.

Results. Using the tcpdump command to store the traces, for different interfaces associated with the bi-directional tunnels, into log files to be examined using Wireshark, the ICMPv6 packets are verified to be tunneled using IP-in-IP encapsulation, and the necessary routes and rules on AR1, CH1, AR2, CH2 are correctly added and verified to be functional.

4.2.3. Scenario 2: Inter-cluster Mobility

Description. This scenario aims at testing if MNs can keep on-going sessions while moving between clusters. In this scenario, once the MN1 and MN2 have been registered to the network, MN1 starts the ping6 traffic to MN2 and later moves from AR1 to AR2. Since this scenario is issued with a low-priority in the scope of our related projects, we did not examine throughout all other possible scenarios of inter-cluster mobility.

Once the MN1 has moved inside the coverage of AR2, AR2 detects the attachment of MN1 and starts the registration procedure for MN1.

AR1 detects the detachment of MN1 thanks to the hint sent by CH. and starts the deregistration procedure. Soft states and routing tables at AR1, AR2, CH1, and CH2 are updated. Session continuity is assured. On-going ping6 sessions can continue.

Results. Using the tcpdump command to store the traces, for different interfaces associated with the bi-directional tunnels, into log files to be examined using Wireshark, the ICMPv6 packets are verified to be tunneled using IP-in-IP encapsulation and the routes and necessary rules on AR1, AR2, CH1 and CH2 are correctly added and verified to be functional.

All PMIP binding cache entries, associated tunnel, rules and routes are well

- 97 -

updated on CH1, CH2, AR1, and AR2. This is verified by the creation of its entry in the PMIP cache of AR2, the update of its entry in CH1 and CH2 and the deletion of the entry in AR1.