S2006-IPI

6. DTN Routing (2): Probabilistic / Un-Planned / Unknown Connectivity Pattern

Topics

• CAR - Context-aware Adaptive Routing
• MEED - Minimum estimated expected delay
• SWIM
• PROPHET

Presentation slides

10. Data Retrieval in Intermittedly Connected Networks

So you´ve got the net, now what about the data it should deliver? After examining different aspects of DTNs from TCP replacements over routing to network coding, this section deals with the actual transport of data. We have a look at two interesting papers: the first one presents a rather new approach to delivery of data, the other one identifies some flaws in the current (2006) DTN architecture that affect data delivery and proposes some enhancements to correct these.

To have a first shallow insight, have a look at our Introductory Speech Slides (PDF)

Distributed Information Retrieval

• Information Retrieval slides

Enhanced Disruption and Fault Tolerant Network

First, I'll try to clarify some DTN-related things and buzzwords, to be able to explain which flaws of the current design EDIFY tries to correct. I'll concentrate on aspects that relate to EDIFY.

The concept of the DTN research group views as DTN as a network of networks, as some sort of overlay on top of other nets, being able to support communication between these (maybe diverse) nets. These possibly diverse nets are also called region in DTN terminology ([1]).

DTN-wide addressing is now done via a tuple (region,locator), where region marks a network and locator a node belonging to this network. Note that addressing within a region/network can be completely different, it's up to the network how this is done. The (R,L)-addresses are specific to the overlying DTN, used to do inter-group addressing.

To actually be able to communicate with different regions, each region possesses at least one special gateway node, translating between the region's own protocol and DTN-speak and resolving global (R,L)-style DTN names into local, region-specific ones.

While this addressing scheme is quite fine with static regions, it is unable to deal with ad hoc or mobile regions.

First, why are ad-hoc regions not supported: The assumption that is made is that nodes within a region are always able to communicate with their region members, gateway nodes being the most crucial ones.

But in reality, this isn't true: regions/networks can be split, i.e. the communication within the region can be disrupted (imagine a platoon of soldiers having to split due to enemy fire). Now there are a number of region members that are unable to talk to their region's gateway. Therefore these nodes are now unreachable from other parts of the DTN...

Another mere management problem is the joining of regions: The traditional approach makes no statements about merging of networks, not answering some important questions: How is the new region called? Does it get the name of the first or the second region coming together? More important: Who is going to be the new region's gateway?

Second, there are problems with mobile regions: Imagine a whole region/network moving around (e.g. some people in a plane). The traditional approach assumes static, non-moving regions/networks and so are it's assumptions about routing. However, with a moving network, one has to think about new aspects of routing data...

These are more or less the core problems that EDIFY tries to solve. They do this mainly using a new naming scheme for DTNs. I tried to summarize the whole story from problems to solution in in a talk, with the slides being downloadable here.