logoliggew bold

                                                    

                                                                   Networking for Communications Challenged Communities:

                                                                   Architecture, Test Beds and Innovative Alliances

System architecture and the project results (security, standards etc)


As we started N4C, we adopted the spiral development model as its working mode. This model fitted well with our sequence of six planned summer and winter testing seasons (summer 2008 through to winter 2010-2011). WP2 provided a ‘checkpoint’ in the cycle of high level planning, low level planning, test execution and results analysis for each testing season. Results from the previous season were assessed from a system and architectural perspective, and we were able to feedback the results into changes to the infrastructure software and overall planning for subsequent test periods. This way of working has proved to be highly successful, with problems being identified in the earlier and generally smaller scale tests, and then fixed so that the later tests were more productive. We can point to a number of areas where the technique has been effective: for example, the need for greater sophistication from the power management in the hardware we used was highlighted by early testing in both Slovenia and Arctic Sweden and the more sophisticated solutions developed have been an important feature in the success of the 2010/2011 test season. Also the PRoPHET routing protocol used in later tests has been significantly improved over the original version as a result of identifying unexpected behaviour in earlier tests. In practice, the Slovenian test bed has actually been running essentially continuously for over 2 years. The specific testing seasons that were envisaged in the project Description of Work (DoW) have been marked by particular additions to the test bed and snapshots of the performance of the test bed, but the testing has continued even outside the specific seasons. The resulting continuity and long term nature of testing has added greatly to the value of testing and has identified issues that would be unlikely to have been found had the testing been totally episodic.


The main forum for discussing and propagating common specifications for DTN, with a view to eventual standardization, is the IRTF DTN Research Group (DTNRG) [DTNRG]. Partners Folly, LTU and TCD have all been actively involved in making contributions to the DTNRG during the course of the N4C project. Stephen Farrell of TCD is one of the co chairs of the research group and has played an active role in ensuring that N4C’s work in DTN is aligned with the aims of the DTN research group. In addition to Stephen Farrell, representatives from LTU and Folly have attended the DTN research group face-to-face meetings either in person or via telepresence. Additionally, representatives of the partners have participated in subsidiary discussions especially related to management of DTNs outside of the main DTNRG. During the development of the N4C test bed infrastructure and applications, N4C partners have investigated and researched various technical aspects of DTN protocols and documented this work through the publication of Internet Drafts for consideration and review by the DTN research group and the wider IETF/IRTF community. Contributions were made to the following areas:


  • Naming of DTN Endpoints through the dtn: URI scheme – documents

  • The DTN URI Scheme [URIscheme]

  • Adding the ‘find’ Operation to the dtn: URI Scheme [URIfind]

  • Endpoint Discovery Protocol for DTN

  • The Delay Tolerant Networking Endpoint Discovery Protocol [EndPoint]

  • Bundle Security Protocol [BSP]

  • Several updates have been made to this document to meet review comments both from within the DTNRG and from IESG and IRSG reviewers prior to its being accepted for publication as an Experimental RFC

  • PRoPHET Routing Protocol [PRoPHET]

  • Extensive experimental, simulation and theoretical work has been done on the PRoPHET Routing Protocol specification, based on interaction between LTU, the N4C Advisory Board member Dr. Anders Lindgren (Swedish Institute of Computer Science), MEIS and Folly Consulting as main author of the last updates. There have been a number of updates to the Internet Draft that specifies the protocol. These versions have been presented to the DTNRG and review comments have been received from various member of the group. The document is expected to be submitted for formal approval very shortly.

  • Self-Defining Numeric Values [SDNV]

  • The Licklider Transmission Protocol [LTP], [LTPcl]

  • DTN Management mechanisms. A sub-group of the DTNRG has been working on this topic intermittently during the period of N4C. Much of this work is still at a very experimental stage and it is not implemented in the DTN2 reference implementation as yet. N4C staff have been involved in this group.

  • Extending the bundle protocol to handle cases where nodes have no good clock [AltTime]

  • Extending the bundle protocol to handle information-centric networking [InfCenNet], [QueryBlk]

The Internet-draft documents associated with a number of these areas have or are expected to become formally reviewed and approved RFCs in the near future. (There are six DTNRG documents currently in the RFC Editor’s publication queue at the time of writing. See [RFCQueue].) N4C staff has provided considerable support and expertise in progressing these and other DTN RG documents through the formal processes necessary for publication as RFCs during the course of N4C. In addition to providing a co-chair for DTNRG, Elwyn Davies (Folly) has acted as ‘document shepherd’ for the current set of DTRNG documents in the RFC editor queue. Within WP2, Folly Consulting (Elwyn Davies) has written and edited a number of documents that will be useful outside the project. For Deliverable 2.1 the N4C team with contributions from several partners, and Mr. Davies as head editor, created an extensive ‘State of the DTN Art’ document [DTNstateArt] covering the technical state of the art and documenting a large number of projects that have used DTN. D2.1 also contains a System Architecture document [N4Carch] [N4Carch][N4Carch]that provides a high level overview of the infrastructure software that has been used in the various experiments in N4C. Two implementations of the DTN infrastructure software following this architecture have been used during N4C. One of these is the Prophet implementation originally developed for the predecessor SNC project and further developed during N4C. The other implementation is the DTN2 Reference Implementation [DTN2]. During the course of N4C responsibility for maintenance of the DTN2 Reference Implementation was transferred to staff from partners TCD and Folly. Alex McMahon of TCD has been primarily responsible for ensuring that this community resource was available to any interested party. The packages were moved to the Sourceforge repository using the Mercurial version control system [Mercurial]. A backup secondary repository was also maintained on Folly's server. The secondary server also delivers a number of additional pieces of N4C specific software which are being released to the community as Open Source software. (http://code.n4c.eu). In addition to basic maintenance of the DTN2 software, N4C staff have made a number of significant contributions to the package:

  • Major additions to the logging system that ensure that bundles can be accurately tracked as they move through a DTN using DTN2 infrastructure. This work was triggered by the difficulties that were encountered in analysing the results of trials during Summer 2009. The improvements have significantly improved the value of the results and the ease of analysis for the Summer 2010 trials.

  • Generation of a functional specification for the DTN2 software, incorporating a full manual of the user management commands that was not previously available. [FuncSpec] Folly Consulting was primarily responsible for this work.

  • The LTP Convergence Layer has been integrated into the DTN2 code by staff from TCD.

One of the aims of N4C was to research DTN friendly security measures. The environment in which the N4C test beds were deployed was relatively non-threatening, but even in such a non-threatening environment, deploying an experimental network required considering security and privacy aspects well in advance, implementing some security measures and handling personal information integrity for months after the end of the trial. Had our experimental network been either closer to a production environment or running in a more typical Internet context, then the amount of work involved would have increased substantially. Nonetheless, we ran our trial and didn't experience any security incidents that we know of, so our relatively minimalist approach seems to have been sufficient. We would hope that others deploying experimental networks and applications might be able to learn from what we've done, but most of all, that they would build security and privacy considerations into their planning – they will in any case, most likely be forced to do that in future as ethical approval becomes commonly required for web and networking experimentation. As we have demonstrated in N4C the tools and mechanisms required are either freely available or else readily developed. In terms of the security requirements posited in the project DoW, we consider we have met almost all of those, but using mechanisms other than those that were planned when the proposal text was written in 2007. The remaining area, AAA (Authentication, Authorization and Accounting) for DTN, was not tackled partly because the only available implementation of the BSP was incomplete and partly because our views as to the layer at which AAA should be implemented moved towards the application layer and away from the DTN transport.


The PRoPHET dynamic routing protocol for DTNs has been extensively used during testing in both Slovenia and Arctic Sweden. The routing protocol has been designed specifically to provide routing in the store, carry and forward paradigm of a DTN where there is no stable topology and data is forwarded during opportunistic encounters between nodes. PRoPHET sets out to exploit the underlying patterns that are almost always present when human activity is linked to the movement of nodes in the network. Folly Consulting has cooperated with researchers at LTU in improving the protocol and updating the specification of the protocol. Input from the extended testing cycles in Slovenia alerted the protocol’s authors to some unexpected behaviour. Inspection of the test results and simulation work at LTU identified the exact situation that was causing the behaviour. Theoretical research by Folly Consulting identified an improvement to the algorithms that govern the evolution of the internal model created dynamically by PRoPHET from the history of encounters and information exchanged during these encounters about the likelihood that other nodes will be encountered. The resulting model is intended to mirror the mobility pattern of nodes in the network so that it can be used to determine the most effective usage of resources for forwarding data to its intended destination. The improved algorithm was implemented for the Summer 2010 tests and appears to have been successful in eliminating the problem. The results from the Summer 2010 tests resulted in further work on the evolution algorithms to deal with situations where connections between nodes repeatedly start and finish, leading PRoPHET to believe that extra encounters have taken place when they are actually artefacts of the wireless connection layer. A simple solution to this problem has also been found by Folly Consulting, and it appears that the combination of the two improvements also resolves a longstanding theoretical issue with PRoPHET: a group of nodes clustered at a single location would result in multiple, potentially circular information transfers. The updated algorithms result in a stable outcome whereas it was previously the case that this could have resulted in unstable behaviour of the model. The various improvements in the algorithms plus improvements to the protocol specification have now been incorporated into the Internet Draft that specifies PRoPHET [PRoPHET] and it is being processed for publication as an Experimental RFC under the auspices of the DTNRG.


Folly Consulting will be exploiting the experience and expertise gained during N4C to market consultancy services in relation to DTN in the future. The company will continue to work especially on the PRoPHET routing protocol and will seek to be involved in further projects working with DTN either as a partner or as a subcontractor. Internally, Folly Consulting is working on the creation of an alternative implementation of the DTN infrastructure that is built on a more widely accepted framework (Qt) than the framework used by DTN2 (Oasys) but is compatible with DTN2 so that existing applications can be used unchanged. It is intended that this will be released as an open source package, and Folly Consulting will be able to exploit it by providing consultancy and implementation services.



This text is fetched and adapted from the Final report summary of WP2 by Elwyn Davies, submitted in July 2011.


References


[AltTime]

Farrell, S, McMahon, A., and Ott, J,. “Handling Issues with Real Time in the Bundle Protocol”, draft-farrell-dtnrg-alt-time-00, November 2009.

[BSP]

Symington, S., Farrell, S., Weiss, H., and Lovell, P., “Bundle Security Protocol Specification”, draft-irtf-dtnrg-bundle-security-15, February 2010.

[Bytewalla]

Bytewalla Project Team, “Bytewalla: Delay Tolerant Network on Android Mobile Phones”, Bytewalla project web site, January 2010

[CBHE]

Burleigh, S., “Compressed Bundle Header Encoding (CBHE)”, draft-irtf-dtnrg-cbhe-04, February 2010.

[Ding]

Clark, G., Campbell, G., Kruse, H. and Ostermann, S., “DING Protocol -- A Protocol For Network Management”, draft-irtf-dtnrg-ding-network-management-02, February 2010.

[DTN2]

Demmer, M., et al, “DTN2 Bundle Protocol Agent Reference Implementation”, Available from Sourceforge DTN Repository or N4C Code Repository.

[DTNRG]

IRTF Delay- and Disruption-Tolerant Research Group Web Site and Wiki.

[DTNstateArt]

Davies, E, et al, “DTN - The State f the Art”, N4C Deliverable D2.1, April 2009,

[DTNnetMgmt]

Ivancic, W., “Delay/Disruption Tolerant Networking - Network Management Requirements”, draft-ivancic-dtnrg-network-management-reqs-00, June 2009.

[EndPoint]

McMahon, A and Fall, K,, “The Delay Tolerant Networking Endpoint Discovery Protocol”, draft-mcmahon-dtnrg-dtn-edp-00, February 2010.

[FuncSpec]

Davies, E, and Doria, A., “Functional Specification for DTN Infrastructure Software”, N4C Deliverable D2.2, April 2010

[InfCenNet]

Kutscher, D., and Farrell, S., “Towards an Information-Centric Internet with more Things”, Submissions for IAB SmartObjects Workshop, February 2011.

[JoUd2010]

Johansson, Anders W. and Udén, Maria. The migration of gender and the labour market. In Wang, I-Chun et al (Edts) Perspectives on Migration, Nationhood, and Ethnicity. Monograph series of National Sun Yat-Sen University, Taiwan. Pp 74-85, 2010

[LiUd2010]

Lindberg, Malin & Udén, Maria. Women, reindeer herding and the Internet: An innovative process in northern Sweden. Innovation: The European Journal of Social Science Research, vol. 23, No. 2, pp. 169-177, 2010

[LTP]

Farrell, S., et al, “Licklider Transmission Protocol – Specification”, RFC 5326, Sep 2008.

[LTPcl]

Burleigh, S., “Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter”, draft-burleigh-dtnrg-ltpcl-03, February 2011.

[N4Carch]

Davies, E, et al, “N4C System Architecture”, N4C Deliverable D2.1, April 2009 (Updated May 2011 - N4C Deliverable D2.1- updated).

[PRoPHET]

Lindgren, A., Doria, A., Davies, E., and Grasic, S., “Probabilistic Routing Protocol for Intermittently Connected Networks”, draft-irtf-dtnrg-prophet-09, April 2011.

[QueryBlk]

Farrell, S., Lynch, A., Kutscher, D., and Lindgren, A., "Bundle Protocol Query Extension Block", draft-farrell-dtnrg-bpq-00, November 2010.

[RFC5050]

Scott, K. and Burleigh., S., “Bundle Protocol Specification”, RFC 5050, November 2007.

[RFC5325]

Burleigh, S., Ramadas, M., and Farrell, S. , “Licklider Transmission Protocol - Motivation”, RFC 5325, September 2008.

[RFC5326]

Ramadas, M., Burleigh, S., and Farrell, S., “Licklider Transmission Protocol - Specification”, RFC 5326, September 2008.

[RFC5327]

Farrell, S., Ramadas, M., and Burleigh, S., “Licklider Transmission Protocol - Security Extensions”, RFC 5327, September 2008.

[RFCQueue]

RFC Editor Publication queue

[SDNV]

Eddy, W. and Davies, E., “Using Self-Delimiting Numeric Values in Protocols”, draft-irtf-dtnrg-sdnv-09, February 2011.

[URIfind]

Davies, E. and Doria, A., “Adding the “find” Operation to the dtn: URI Scheme”,
draft-davies-dtnrg-uri-find-01, October 2009.

[URIscheme]

Fall, K., Burleigh, S., Doria, A., and Ott, J., “The DTN URI Scheme”,
draft-irtf-dtnrg-dtn-uri-scheme-00, March 2009.