Projecte

General

Perfil

Actions
Historial

Mobility performance Evaluation of Mesh rOuting protocols (MEMO)

Experimentation Project executed by RouteK S.L. as part of Federation for FIRE integrated project and funded as Innovative Experiments by SMEs Fed4FIRE-SME-1

Project Summary

In contrast to traditional IP-mobility solutions (like MIPv6), which require a pre-deployed infrastructure and are limited to the coverage range of the core-backbone nodes, a fully mesh-based solution can conceptually provide a self-organized network that does not require any pre-deployed infrastructure and which’s coverage expands as nodes participate in the network. However, the performance of mesh networks in the presence of mobile mesh nodes is unclear.

This project focuses, from an experimental point of view, on the capabilities of several mesh routing protocols (Babel, BMX6, BATMAN-adv, OLSR, and IEEE802.11s) for supporting mobile mesh nodes. These investigations are of significant interest because the demand for seamless mobility has become imperative for the users.

Related experiments will be prepared using emulab - total network testbed and executed in w-iLab.t Zwijnaarde (iMinds) and Community-lab (UPC) Fed4FIRE testbeds because both of them support the configuration of wireless nodes similar to our standard deployments and are suitable to perform mobility tests.

Concept and objectives

The main question we are seeking to answer with this experiment is (i) if and to what extend traditional IP-mobility solutions for wireless networks (like MIPv6) can be substituted with full-mesh based solutions and (ii) to what extend the existence of mobile nodes, and thereby introduced temporary and highly dynamic links, affects the end-to-end performance of stationary nodes.

To answer this question, the objective of this proposal is to analyze state-of-the-art routing protocol solutions regarding their capabilities for supporting topology dynamics caused by mobile mesh nodes.
The mobility support will be measured by means of the maximum amount of topology changes a protocol can handle while maintaining a continuous connection between (i) a mobile node and a stationary destination node and (ii) two stationary nodes which's possible end-to-end path include links via a mobile node.
The exact metric for ranking the mobility performance of a protocol is given by a reference experiments. In addition, relevant cost factors for achieving an identified mobility performance will be captured as needed for providing a fair analysis of each's protocol advantages and disadvantages.

The main objective of our concluding analysis is to provide benchmarking results and guidelines that allow to estimate and predict to some extend the feasibility for supporting a given use case with a particular routing protocol.

Outlook

The project execution will officially start by June 1st and end by September 30 2014
This wiki will be updated over time.

Procedures relevant for this project

There is a work-in-progress tutorial here:
https://dev.qmp.cat/projects/memo/repository/revisions/master/entry/TUTORIAL.md

Feedback

..and findings on F4F API, federation, usage, and documentation

The first contact following the suggested intros , tutorial , jFed and ilabt documentations yield to instant success. Within few hours it was possible to pass the registration procedure and successfully execute a simple experiment with two unbound wireless nodes in the w-ilab.t testbed, showing reasonable ping latencies and losses depending on configured transmit power. Congratulation for the good and intuitive integration and documentation.

During a first kick-off teleconference with our mentors further (more advanced) issued were identified and discussed. These issues as well as their temporary solutions (and possible later issues as will likely be encountered during the project) are collected for concluding feedback in the following.

Federation of accounts and required registrations

Some minor confusion raised due to different existing registration portals and domains.
  • emulab represents kind of reference portal but is not needed for F4F participation. Emulab-based experiment specification use NS syntax and registration procedures of following (required) portals are based on this.
  • wall2 provides the recommended registration portal for F4F participation when using jFed and Rspecs API
  • wilab2 registration is required for F4F participation in case of emulab (NS) experiment-specification API is preferred (although not suggested). A registration is also needed for reviewing the allocation table of specific (wireless) nodes and for exclusive slot-reservation of nodes for a F4F experiment. The federation of wall2 and wilab2 registration and resource reservation is planned. [PENDING registration approval]

Using OpenWRT based node OS images

Due to the active wireless development and its optimizations for embedded wireless-router devices of OpenWRT based systems we are preferring OpenWrt based node images for our experiments

  • Documentation for preparing and deploying customized node images is provided only for pcgen1 nodes. [TBD]
    Aiming for Zotac and OpenWRT nodes we agreed on the following procedure:
  • User prepares desired tar.gz image (using network configuration of already-provided openWRT images)
    • default password?? [TBD]
  • Requests further image testing and adaption via email to testbed admins for enabling them.

Outband experimentation-data access

Documentation for accessing experimentation data of inactive experiments lacked access description. The explained approach is via central data login :
  • in generic testbed node there is a NFS mountpoint at /groups/wall2-ilabt-iminds-be/memo
  • data access via node only (to shared nfs)
  • offline data access not possible yet:
    • via scp/ssh with wall2/JFed userid and pw [CLARIFIED]
    • or scp/ssh -i ~/.../proj/.../fed4fire/ssl_id.private.rsa ops.wall2.ilabt.iminds.be and Geni SSL passphrase
    • project related directories:
      • /data/users/USERID
      • /groups/MEMO/MEMO -> /proj/MEMO
      • /groups/wall2-ilabt-iminds-be/{.|memo|MEMO} is all permission denied [TODO]

Documentation and procedure for exclusive registration of specific nodes for F4F wall2 testbed.

  • using jFed for managing experiments, Wireless nodes should not be used unless reserved manually and beforehand because these nodes are "IMinds WiLab 2" nodes which dynamic allocation conflicts with emulab reservations.
The agreed procedure is:
  • Reserve desired nodes and allocation slot via private mail so they are blocked for others
  • Define registered nodes via RSpec or (graphical API node name).

Documentation on controlling wireless-mobile-node movements in w-iLab.t testbed

The agreed procedure is:

Actualitzat per Axel Neumann fa més de 10 anys · 2 revisions