In setting out to implement the DTN architecture, we first had to resolve some fundamental
questions in the architecture itself, and in the process, further its design and
specification. One of the more unusual aspects of the operating environments envisioned for
the DTN architecture is that the ability to communicate may come and go, and that sometimes
the periods of connectivity may be known (or predicted) in advance. In addition, communication
may involve routing messages over one or more media, possibly simultaneously. Although this
degree of flexibility is important to an overall network model that is expected to operated in
difficult environments subject to disruption, it presents significant implementation challenges.
The challenges stem largely from the fact that the DTN network model is not simply a graph, as
in most present networking systems, but instead is a time varying multigraph. There is at
present little shared experience in implementing networking systems involving graphs of this kind.
Figure 1: Example DTN network
In the spirit of previous work in DTN, we begin with the village s cenario of Figure 1. There are
three methods used to transfer data between the village and the city: traditional modem links,
low-earth orbit satellite links, and a mobile “commuter bus” link that will carry messages
physically. This real-world situation is abstracted, according the DTN architecture, as the graph
in Figure 2. Here, the cities and villages are represented by nodes and various connectivity
options by edges. The city bus is represented by an edge in this figure, but as we shall discuss
below, other representations are possible and may even be preferable.
Figure 2: Example network model