2005:139 CIV
M A S T E R ' S T H E S I S
Implementation and Analysis of the Bundling Protocol for Delay-Tolerant Network
Architectures
Henrik Eriksson Patrik Jönsson
Luleå University of Technology MSc Programmes in Engineering
Department of Computer Science and Electrical Engineering Division of Computer Communication
2005:139 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--05/139--SE
Implementation and Analysis of the Bundling Protocol for Delay-Tolerant Network
Architectures
Henrik Eriksson Patrik Jönsson
I love deadlines. I like the whooshing sound they make as they fly by.
Douglas Adams
Abstract
When dealing with networks with long delay and intermittent connectivity be- tween nodes, data can have trouble getting through to its destination. Delay- tolerant networks can solve such problems by providing reliable data transfer using the new bundling protocol with a store-and-forward technique.
For allowing in-depth analysis of this protocol, there is a need to have means for running simulations in different network environments. This thesis describes the implementation of a simulation model for running simulations on delay- tolerant networks in a network simulator.
Some simple simulations are run, showing basic characteristics and func-
tionality when using various features of the DTN architecture and the bundling
protocol for transmission.
ii
Contents
Preface v
1 Introduction 1
1.1 Purpose . . . . 1
1.2 Objective . . . . 1
2 Background and related work 3 2.1 Background . . . . 3
2.2 The concepts of DTN . . . . 4
2.2.1 Bundles . . . . 4
2.2.2 Custodial transfer . . . . 5
2.2.3 Regions and nodes . . . . 5
2.2.4 Routing . . . . 5
2.2.5 Security . . . . 6
2.3 Related work . . . . 6
2.3.1 Internet Drafts, papers and tutorials . . . . 7
2.3.2 Interplanetary Internet . . . . 7
2.3.3 DTN reference implementation . . . . 7
2.3.4 Sámi Network Connectivity . . . . 7
3 Methodology 9 3.1 Research . . . . 9
3.1.1 DTN Internet Drafts . . . . 9
3.1.2 DTN reference implementation . . . . 9
3.2 Simulation model . . . . 10
3.2.1 Implementation . . . . 10
3.2.2 Ns-2 . . . . 10
3.2.3 Nam . . . . 11
3.3 Simulation . . . . 12
3.3.1 Test setup . . . . 12
3.3.2 Data processing . . . . 13
4 Analysis and evaluation 15 4.1 Simulation model . . . . 15
4.1.1 Routing . . . . 15
4.1.2 Custodial transfer . . . . 16
4.1.3 Status reports . . . . 16
4.1.4 Limitations . . . . 16
iii
iv CONTENTS
4.2 Simulation results . . . . 16
4.2.1 End-to-end delay . . . . 17
4.2.2 Delivery ratio . . . . 18
5 Conclusions 21 5.1 The bundling protocol . . . . 21
5.1.1 Internet drafts . . . . 21
5.1.2 Applications . . . . 21
5.1.3 Registrations . . . . 21
5.1.4 Security . . . . 22
5.2 DTN implementation . . . . 22
5.3 Simulation model . . . . 22
5.3.1 Routing . . . . 23
5.3.2 Custodial transfer . . . . 23
5.3.3 Status reports . . . . 24
5.3.4 Future work . . . . 24
Bibliography 27 A User guide 29 A.1 Introduction . . . . 29
A.2 Node command interface . . . . 29
A.2.1 Setup . . . . 29
A.2.2 Runtime . . . . 30
A.2.3 Callback functions . . . . 32
A.3 NS-2 variables . . . . 34
A.4 Examples . . . . 34
A.4.1 Small network . . . . 34
A.4.2 Large network . . . . 36
Preface
Sometimes a project takes a little bit more time than what was originally intended, sometimes a lot. We would like to thank our supervisor Kaustubh Phanse for his patience with our constantly changing time plan.
In time or not, it has been interesting studying the delay-tolerant networking concepts and an enriching experience working with the simulation model, despite the somewhat inflexible ns-2 simulator.
Luleå, April 2005 Henrik Eriksson and Patrik Jönsson
v
vi
Chapter 1
Introduction
Communications over the Internet is today mainly done through a rather ho- mogeneous set of links, with relatively high bandwidth and low delay. However, a scenario of this type is not applicable to some types of communications, either because the destination is too far away or simply because there is no Internet infrastructure nearby. In these cases, the Delay-Tolerant Networking concept can provide means for satisfactory data transfer.
DTN provides an extra layer between an application and a network, allowing data to be sent reliably over intermittent or long-haul links. This can be used in an interplanetary network between the earth and Mars, or by nomadic people who passes each other or some other node that can relay a message closer to its destination.
1.1 Purpose
The purpose of this thesis is to provide means for analysis of the DTN bundling protocol in different network architectures.
Furthermore, it aims to evaluate and analyse the protocol in terms of ba- sic properties and performance. These evaluations also allow for later cross- validation with a corresponding real network implementation.
1.2 Objective
This thesis includes implementation of a simulation model of the DTN bundling protocol. The implementation is based on the DTN bundling proto- col version 3 and includes most of the specific DTN features, such as custodial transfer.
Analysis of the bundling protocol is done on results provided by simula- tions using the implemented simulation model. The simulations are done in the network simulator ns-2 in a range of different scenarios.
The results produced by the different simulations are processed using statis- tical functions and visualised in graphs to provide a sound basis for analysis.
1
2
Chapter 2
Background and related work
2.1 Background
With the expansion of Internet to remote locations and areas far away from existing Internet infrastructure, such as in interplanetary networks or when pro- viding connectivity for nomadic people, traditional communication technologies may be rendered infeasible. The most common protocols used in the Internet today, e.g. TCP and UDP, are designed for a network with continuous end-to- end paths between source and destination, with relatively high bandwidth and low delays, providing for short round-trip times of packets. Because of this, a network with long delay and intermittent connectivity between nodes causes problems for ordinary transport protocols, especially connection-oriented ones such as TCP, that needs to establish a connection with the destination before sending data. The problem of a TCP session timing out caused by too long delay is also an issue when dealing with asymmetric data rates. Large asymmetries can introduce delays, causing TCP not to function properly.
In some cases a node or a link may be unavailable for a very long period of time, generating long delay for data waiting to be sent. Besides sporadic loss of connection, a fluctuating link can also cause high error rates in transmissions when data gets dropped or not transferred completely.
With tolerance for delays and intermittent connectivity, the DTN architec- ture can solve problems related to communications over unstable links, and can handle nodes or links being unavailable for several days, still being able to provide reliable data transfer thanks to buffering in the network.
The DTN protocols are currently under development, where specifications of these are still a work in progress. The DTN bundling protocol
1, defining a way to send information between networks that are unable to communicate with each other directly, has been implemented for use in a real network but there has not been much testing and evaluation done on this code or the protocol.
Although an implementation can be used for testing and running experiments on a network, a large and complex network structure with different characteristics can be difficult to set up in practice. Using a simulation model makes it easy to obtain reproducible results in simulations and cost-effective evaluation of larger networks.
1
Further discussed in section 2.2.
3
4 CHAPTER 2. BACKGROUND AND RELATED WORK
Figure 2.1: Top three layers of the DTN network stack
2.2 The concepts of DTN
The key part in DTN is the bundling protocol described by Delay-Tolerant Network Architecture[1]and Bundle Protocol Specification[2]. The bundling protocol allows hosts that normally cannot communicate with each other, due to network partitioning or because they do not have the same protocol set, to be able to communicate.
This is done using message switching, which means that only adjacent nodes needs to share the same protocol set, and multiple protocol sets are only required in nodes bridging protocol borders.
The protocol uses existing transport protocols for data transmission but also acts as a transport protocol to applications, making it noncompliant with the traditional layer model for internet communication. Instead of categorising the bundling protocol as a transport layer protocol, a new layer, called convergence layer, is added between the application and transport layers, shown in figure 2.1.
This also implies that applications need to be adapted to use the bundling services.
2.2.1 Bundles
As with all information transmission the data must be packaged before trans- mission. In DTN this entity is called a bundle.
The bundle is used to attach additional information to the payload, needed by nodes to correctly transfer the data. In addition to the source and destination fields, fields for delivery options and handling can be included.
The available options include custodial transfer and reporting, end-to-end return receipts and security credentials.
2.2.1.1 Bundle structure
Each bundle consists of one or more headers, stacked after each other, as illustrated in figure 2.2. The first one, the primary header contains delivery options and references to addresses stored in a succeeding dictionary header.
Other possible headers can follow in a non-specific order, with the only exception
that the payload header is placed at the very end. The payload is placed last to
allow for dynamic fragmentation in case of a link failure during transmission,
which means that in case of a link drop-out at the end of a transmission only
the last part needs to be resent. This can be used to always maximise link
usage. Because of this, the payload header has no information about any trailing
header, whereas other headers include this next-header information.
2.2. THE CONCEPTS OF DTN 5
Payload header Dictionary header
Primary header
Figure 2.2: Bundle structure
2.2.1.2 Administrative payloads
A node sending a bundle can request reports of what happens to the bundle during its journey to the destination. These so called status report are placed in the payload of a new bundle, as a different payload type, and sent to a specified report-to address.
2.2.2 Custodial transfer
A sending node can request custodial transfer of a bundle, meaning that any node on the path can take custody of the bundle. If a node chooses to take custody of a bundle, it takes over all responsibilities regarding the bundle, such as retransmission, and related resources can be released from the previous custodian.
2.2.3 Regions and nodes
A large DTN network can consist of nodes from several different network topologies, each with a different addressing scheme. The use of different ad- dressing schemes is usually a reason why nodes from different networks are unable to communicate.
DTN solves this problem by defining a region part in the endpoint ID, the DTN addressing scheme. DTN regions are defined in Delay-Tolerant Network Architecture[1] and a region can be described as a group of nodes in a network, using the same protocol set for communication.
Since nodes in different regions often use different protocol sets, consequently using different addressing schemes, only the region part of the endpoint ID is meaningful until the bundle has arrived somewhere within its destination region, where the other, administrative part of the endpoint ID can be interpreted for correct delivery.
The naming scheme used in the region part of the endpoint ID is similar to the DNS topology, i.e. a tree structure with the root last.
2.2.4 Routing
In DTN, routing is primarily done based on the region part of the endpoint
ID and then according to local rules used by each network topology.
6 CHAPTER 2. BACKGROUND AND RELATED WORK
It is not defined in detail how the routing should be done in practice; instead this is left for the implementation, since it is not necessarily done consistently and can depend on network characteristics.
As an aid in defining rules for routing decisions, a few different contact types has been defined.
Persistent contacts Used between nodes that have a persistent network con- nection, e.g. a node connecting through a DSL connection.
On-demand contacts Used by a node that can establish a connection when needed, for instance using a dial-up connection. It is of course only the nodes that can instantiate the connection that sees it as an on-demand contact.
Intermittent - Scheduled contacts Used to define nodes that are available for communication at certain predetermined times, like a low orbit satel- lite.
Intermittent - Opportunistic contacts Used for irregular connection where no assumptions are made regarding when it will be available.
Predicted contacts Used as a hybrid between scheduled and opportunistic contacts where a possible future connection is predicted based on a mobile node’s current movement pattern.
2.2.5 Security
Since the resources of a DTN network can be limited, steps need to be taken to ensure that only the intended data is accepted into the network. To accom- plish this, two additional headers are used; payload security and authentication header.
The payload security header is used to verify the payload integrity, and can also be used to authenticate the original sender on an end-to-end basis.
Verification is done by calculating a hash of the payload and comparing it to the hash supplied in the header, whereas the authenticity is verified by checking a supplied signature of the hash. Hashing and signing are done using common algorithms and asymmetric keys. The services provided by the payload header can also be implemented in applications allowing for more flexibility regarding new functionality.
The authentication header is on the other hand used to verify the entire bundle on a hop-by-hop basis, using the same types of hashes and signatures as in the payload verification. The use of a hop-by-hop verification has several benefits, such as early discard of non-authenticated or damaged bundles and simplified key exchange. The benefits of the simpler key exchange is achieved because a node will only need to know the keys of adjacent nodes and any end node it communicates with, greatly reducing the number of keys a node needs to store and also the time and resources used on a key update.
2.3 Related work
Even though the DTN concept has been under discussion for quite a long
time, there are not many real implementations, mostly theoretical concepts and
2.3. RELATED WORK 7
visions such as communications with other planets. There are however a couple of interesting projects regarding this area.
2.3.1 Internet Drafts, papers and tutorials
Forrest Warthman has written a tutorial[3] describing delay-tolerant net- works and the basic concepts of DTN.
There are some papers concerning routing in delay-tolerant networks; Rout- ing in a Delay Tolerant Network[4], discussing different ways of routing and presenting algorithms for this, and Probabilistic Routing in Intermittently Con- nected Networks[5] dealing with routing using probabilistic methods based on moving patterns for mobile nodes.
The Licklider Transmission Protocol[6] is intended to serve as a convergence layer for the DTN bundling protocol, providing reliable transmission of bundles.
Issues regarding custody transfer of bundles are discussed in Custody Trans- fer for Reliable Delivery in Delay Tolerant Networks[7].
2.3.2 Interplanetary Internet
The IPN Special Interest Group[8] is currently working on a project aiming to define an architecture and the protocols necessary for communication between different networks resident on different planets or spacecraft.
The architecture is required to cope with intermittent connectivity as well as high error rates, thus is expected to be delay-tolerant.
2.3.3 DTN reference implementation
There is an existing implementation of the DTN bundling protocol, released by the Delay-Tolerant Networking Research Group, DTNRG[9], in 2003 as ver- sion 0.1. It is based on the first version of the bundling protocol, specified in the first release of the Bundle Protocol Specification Internet Draft.
2.3.4 Sámi Network Connectivity
Remote and geographically complex areas causes problems for common net- work technologies, mainly in terms of accessibility. The Sámi Network Con- nectivity, or SNC[10], project aims to develop a network technology capable of serving such areas.
The project’s main objective is to provide reliable Internet connectivity for the nomadic Sámi population in northern Sweden. During the year they move with their reindeer herds in search for pasture through different areas with topographical variations, and consequently different possibilities for Internet connection.
SNC is based on the DTN concept, combined with opportunistic routing in a
network of wireless communication points and mobile relays. This combination
provides for what can be considered as reliable connectivity, though with highly
varying and sometimes very high delay.
8
Chapter 3
Methodology
3.1 Research
There is a lot of documentation in papers, specifications and reports describ- ing delay-tolerant networking. Besides gaining knowledge of the basic features of DTN, studies are required of the different internet drafts specifying the bundling protocol and bundle structure.
The DTN tutorial [3] provides a high-level description of DTN, giving a simple tour of the DTN concept and the bundling protocol. A lot of information is also available on the DTNRG[9] web site and through their mailing list.
3.1.1 DTN Internet Drafts
The DTN Internet drafts specify the bundling protocol and bundle structure.
Because they are still drafts, the documents are updated continuously and can be changed significantly between versions. The relevant drafts are the Delay- Tolerant Network Architecture[1], Bundle Protocol Specification[2] and Delay- Tolerant Networking: An Example Interplanetary Internet Bundle Transfer[11].
3.1.2 DTN reference implementation
The DTN reference implementation, called DTN1[12] is developed to pro- vide a test suite for running experiments connected to the DTN architecture, primarily the bundling protocol. The implementation contains functions for transmission and handling of bundles, including some test applications. This can be used to verify the implemented simulation model and compare selected metrics.
In order to use the implementation for meaningful comparisons and valida- tions of the simulation model, it is imperative that the existing implementation functions properly. A problem with the DTN1 implementation is that some fea- tures are not implemented. Most significantly, there is no support for custody transfer, a central part of the bundling protocol. There are also various bugs in the code, causing intermittent crashes. Because of this, it is of very little use for validating the simulation model.
9
10 CHAPTER 3. METHODOLOGY
Bundle manager
Routes DTN agent
Bundle record Application
Data packaging
etc.
Figure 3.1: General layout of the implemented simulation model
3.2 Simulation model
The simulation model is implemented for ns-2 in C++ and uses TCL scripts for runtime interfacing with the simulator.
3.2.1 Implementation
The implementation of the simulation model is broken down into indepen- dent and easy manageable parts. Figure 3.1 shows the general layout.
Focus is placed on sending and forwarding of bundles and custodial transfers with retransmission capabilities. No security functions, such as bundle authen- ticity and encryption are implemented.
The main part is the Bundle manager, delegating tasks to underlying com- ponents and functioning as a central part of the bundle management. The DTN agent is responsible for the communication interfaces towards both simulator and clients. Other components, used by both the Bundle manager and the DTN agent, handle specific functions such as routing decisions, data packaging and client registrations.
Different log files can be produced, configured at compile time, providing bundle traces or dumps of entire packets.
3.2.2 Ns-2
Ns-2[13] is a network simulator, used for simulating different network topolo- gies and protocols. Using ns-2 for testing has several advantages compared to setting up a complete test network.
One of the main advantages of using simulations compared to real networks for testing is that a simulation environment is much cheaper to set up, and is also usually faster to setup because the simulator only needs a topology description.
It takes considerably less space since only a few simulation machines are needed, and not a complete network with a lot of machines, cables and switches or routers. The results are also easier to compare because of a more controlled environment.
On the downside of using a simulator is the fact that the simulator usually
has its own code base, meaning that any protocol to be tested should interop-
erate with the simulator. Another disadvantage is that it can be difficult to
3.2. SIMULATION MODEL 11
Figure 3.2: Nam showing a simulated network
validate simulations, since simulation models often are based on assumptions made regarding the network environment.
In order to use ns-2 for DTN testing, the ns-2 code needs to be modified to support the new protocol. The ns-2 architecture supports two ways for imple- menting a new protocol; by runtime parsed TCL code and by implementing and adding new C++ classes. The update to support DTN needs to be done mainly in C++ since the code would be too inefficient implemented only in TCL.
3.2.3 Nam
Nam[14] (Network animator) is used to visualise network traffic from packet trace data that can be produced by a network simulator, such as ns-2, or traffic logs. In addition to visualising packet flows, nam also allows packets to be colour coded based on preference by the protocol, seen in figure 3.2 and can show nodes’
native packet queues, which allows for easy identification of bottlenecks. Nam can also be used to visualise a network setup or topology.
In this thesis, nam is used to verify that the setup behaves as intended
regarding routing and basic operation. Colour coding of the different bundle
types, thus visually separating ordinary bundles from status reports and custody
acknowledgements makes it possible to make a rough verification of the intended
functionality.
12 CHAPTER 3. METHODOLOGY
1 2 3
Region 1 Region 2 Region 3
Figure 3.3: Network setup
3.3 Simulation
As a simulator allows for results to be reproducible, the properties and pa- rameters used in simulations need to be easy to set. For the simulation model for ns-2, these are set in TCL-scripts, where the network topology also is speci- fied. To further simplify the process of setting different parameters, shell scripts specifying the parameters are used for starting simulation processes during the evaluation.
Since the bundling protocol is a relatively new and not fully developed pro- tocol, with no direct relation to traditional transport protocols, it does not fit directly into existing network stacks. This makes it difficult to make compara- tive tests and evaluations to other protocols.
Comparisons can be done to the DTN reference implementation[12] available, but the results from these only validates the simulator implementation. In order to evaluate the bundling protocol, a set of selected parameters need to be used in simulations to acquire meaningful results and metrics.
There are two main metrics to study when sending a bundle from one node to another in a DTN network; end-to-end delay and delivery ratio. The end-to- end delay is the time it takes for a bundle to reach its destination, and delivery ratio is the amount of bundles received out of all bundles being sent towards the destination. The latter one is interesting to look into in two different scenarios;
firstly the behaviour when links are not available all the time, and secondly with different expiration times for bundles.
Besides testing with different link availabilities, also the data load of the network, the rate at which data is sent onto the network, is varied.
Factors that are modified in different simulations include expiration time, or time-to-live of bundles, and retransmission timer. Other factors, such as MTU and payload size can also be modified if desired, but are kept constant throughout the simulations.
All simulations are run both with and without custodial transfer enabled, allowing evaluation of the effectiveness of the feature.
Allowing infinite buffer sizes in nodes allows for studies on how much buffer- ing is done in the network, and also assures that the delivery ratio measurement is not affected by bundles being discarded due to full buffers.
3.3.1 Test setup
The ns-2 network simulator allows for simulations in very large networks.
This can be used to study large scale properties of a protocol in a network.
However, the focus lies on the basic properties of data being sent from one node to another. Hence, the simulation environment is narrowed down to avoid strange factors affecting the results.
During simulations focus is placed on three nodes in a network, each node
resident in a different DTN region, shown in figure 3.3. For simplicity, and to
3.3. SIMULATION 13
avoid routing issues, there is only one route between the nodes. The fact that the nodes are located in different regions does not affect the simulations, it is merely an addressing issue.
Bundles are inserted directly into the network using a constant traffic gen- erator provided by ns-2. To further simplify the scenario, there is no other data interfering with the simulation related data.
When changing the link availability, only the link between the forwarding node and destination node is affected. The link availability is controlled using ns-2 built-in functions for network dynamics, with randomly calculated up and down times.
3.3.2 Data processing
When simulations are done, some data processing needs to be done to re- trieve constructive information from the simulation results. Statistics are calcu- lated using the Statistics::PointEstimation[15] Perl module, using information from log files containing bundle traces and queue sizes.
In order to get good statistical results, each simulation run sends data for 100 seconds. The bundle payload size is 100 bytes, resulting in a bundle size of approximately 165 bytes due to header information. For the link availability metric, the data load is 2 000 bytes per second, meaning that approximately 2 000 bundles will be transmitted during each simulation run. For the load metric, the link availability is set to 80%. This is an arbitrarily selected value, representing intermittent connectivity. All simulations are run five times, pro- viding nearly 10 000 samples from which to retrieve statistical data. The values are averaged over all simulation runs and are computed using a 95% confidence interval.
Graphs showing the calculated metrics versus factors and the different pa-
rameters are generated using gnuplot[16]. Confidence intervals are used to val-
idate the graphs.
14
Chapter 4
Analysis and evaluation
4.1 Simulation model
The simulation model provides an environment for evaluation of the DTN bundling protocol. It has support for most of the functions described in the specifications[1, 2], including custodial transfer and bundle fragmentation. It does however not handle any security related functions.
The behaviour of the simulation model is configured via variables available through the TCL-environment, which is also used for controlling the simulation.
Although simulators tend to run rather slow, poor performance is not solely because of ns-2 but also depending on the design of the simulation model. This model is not built for speed and it can take a lot of computational power and time to simulate only a couple of seconds, depending on selected options and parameters.
A detailed description on usage of the simulation model is available in Ap- pendix A, User guide.
4.1.1 Routing
The simulation model uses a static routing table that is populated manually during simulation setup. For every route added to the table, the actual link used is automatically determined to allow the agent to keep track of link usage.
It only allows one bundle at a time to be in transmission for priority to work properly. The routing system can handle multiple links for the same destination region, and can prioritise them using metrics specified when adding the route.
The actual routing decisions can be broken down into two scenarios. The first one occurs when sending a bundle to a node in the same region as the current sending node. Here the underlying networks own routing system is used to find out which link should be used to forward the bundle.
Unless the underlying network provides multiple paths for a single destina- tion only one link will be used to forward a bundle towards a specific destination, delaying the bundle until the link is available.
The second routing scenario takes place when sending a bundle to another region, where the routing table is used to find the best matching link that currently is available using link status information and route metrics.
15
16 CHAPTER 4. ANALYSIS AND EVALUATION
In a partitioned network bundles destined for another partition cannot get through to their destinations. If the partitioned network has more than one possible path bundles risk to be sent from one node to another and back again ad infinitum, filling the link with unnecessary traffic and never taking the infor- mation any closer to its destination. To prevent this from happening the link from which the bundle was received is not used until the bundle has waited some time. This avoids saturation of a specific link when all paths are temporarily unavailable. Link saturation may however still occur if three nodes or more are involved in a network loop, as only one previous node is known.
4.1.2 Custodial transfer
When bundles are sent with custodial transfer enabled, additional processing is needed every time such a bundle is handled at a node.
When a new bundle is initiated the creating node adds its own address as the current custodian. When a node receives a bundle and decides to take custody of it, the node updates the current custodian information and generates a custody acknowledgement.
If a node has not received a custody acknowledgement after some time, specified by the retransmission timer, it will try to send the original bundle again and restart waiting.
4.1.3 Status reports
The simulation model supports generation of any status report, including those used for custody transfers. The priority and expiration time of the bundles carrying the various status reports are set to the same value as of the bundle for which they were generated.
4.1.4 Limitations
There are some limitations in the simulation model, the main one being security features. All security functions have been left out as they were not essential for this study.
Another limitation is that the routing system has no way of handling routes dynamically. Although routing is not included in the bundling protocol, it is an essential part of a network and needs to be included in the simulation model.
The model’s static routing makes it difficult to test mobile scenarios and a replacement algorithm could be developed for testing of such scenarios.
The simulations use a static retransmission timer, but the model supports changing of the value through the TCL-environment.
The bundle manager only considers the first registration for an endpoint ID when delivering bundles, but since the data indication does not include the registration token; multiple deliveries can not be distinguished anyhow.
4.2 Simulation results
We have studied different characteristics of the Bundling protocol when using
various features of the DTN architecture for data transfer.
4.2. SIMULATION RESULTS 17
0.01 0.1 1 10 100
0 10 20 30 40 50 60 70 80 90 100
End-to-end delay (s)
Link availability (%) With custody
Without custody
Figure 4.1: End-to-end delay without bun- dle expiration, varying link availability
0.01 0.1 1 10 100
0 2000 4000 6000 8000 10000
End-to-end delay (s)
Load (bytes/s) With custody Without custody
Figure 4.2: End-to-end delay without bun- dle expiration, varying load
70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Delivery ratio (%)
Link availability (%) With custody Without custody
Figure 4.3: Delivery ratio without bundle expiration, varying link availability
100 1000 10000 100000
0 2000 4000 6000 8000 10000
Largest buffer size (bytes)
Load (bytes/s) With custody Without custody
Figure 4.4: Buffer sizes at different loads
The behaviour of end-to-end delay and delivery ratio is studied at both dif- ferent data loads and different link availabilities. The load specified in the plots and when referring to data load is the amount of data sent from an application.
Additionally, the impact of changing bundle expiration time is considered, and for simulations using custodial transfer the retransmission timer has also been varied.
For all simulations, the MTU of the network is 1 500 bytes and each bundle carries a payload of 100 bytes. In simulations with varying link availability, the data load is set to 2 000 bytes per second, while simulations with varying data load have the link availability set to 80%.
4.2.1 End-to-end delay
When looking at end-to-end delay, the first thing noticed is that there is an increase in delay when using custodial transfer, visible in figures 4.1 and 4.2. The curves showing custodial transfer is based on simulations using a retransmission timer of 50 seconds. In this case there is a large difference between the two curves, regardless of link availability and data load. For lower retransmission timers, the difference in delay is smaller, but it is still higher than without custody.
The end-to-end delay is higher when using custodial transfer because of retransmissions causing extra delay for bundles in need of retransmission. With a retransmission timer of 50 seconds, the additional delay is 50 seconds.
Because of the custodial transfer mechanism the total load on the network
18 CHAPTER 4. ANALYSIS AND EVALUATION
is increased, as seen by the buffer sizes shown in figure 4.4. As the bundle payload size is relatively small, the increase in overhead because of custody acknowledgements is significantly high. The additional overhead causes extra strain on the network, further increasing the end-to-end delay.
With high network load, there is a larger risk for congestion. As custodial transfer increases the network load, it decreases the network’s durability for congestion, lowering the maximum payload throughput. This can be seen in figure 4.2, where the end-to-end delay with custodial transfer starts to increase at a lower load than without.
Although custodial transfer leads to higher end-to-end delay, figure 4.3 shows that it provides for a higher delivery ratio. Without custodial transfer, as the transmission is unreliable and connectionless, data being lost due to link drops is really lost. When using custodial transfer the retransmission mechanism ensures that data never will be lost, giving a delivery ratio of 100%, at least for as long as a bundle is valid and has not expired.
4.2.2 Delivery ratio
An interesting phenomenon is encountered when studying the plots showing delivery ratio at different link availabilities and bundle expiration times in figures 4.5, 4.6 and 4.7, each with a different retransmission timer.
The curves for expiration times 5 and 25 seconds only acts as what could be expected, both in relation to each other and also to the other expiration times, with a retransmission timer of 50 seconds. The strange thing of this behaviour is that none of the bundles sent in that case are ever retransmitted if lost, as they expire before then. There is no simple explanation for this behaviour, as it depends on many different factors and circumstances.
Considering the plots, the first thing to look closer at is the behaviour of the curves for expiration times 5 and 25 seconds. Generally speaking, a higher bundle expiration time would result in a better delivery ratio, as bundles would have more time getting through to their destination. When using a retransmis- sion timer of 0.5 seconds, the delivery ratio for bundles with expiration times 5 and 25 seconds is however much lower than for expiration time 1 second.
When looking at the behaviour of the curve for expiration time 1 second, the ratio interestingly does not seem to be affected by the different retransmission timers. When setting the retransmission timer higher than the bundle expira- tion time, all bundles will obviously expire before ever having a chance to be retransmitted. This means that for retransmission timer 5 and 50 seconds none of the bundles with expiration time 1 second will be retransmitted. This can be seen in the respective plots, where the delivery ratio instantly drops as soon as the link availability starts to decrease.
The delivery ratio would then be better with a retransmission timer of 0.5 seconds. It is in fact slightly better, however not showing a great improvement.
As seen in figure 4.5, the ratio stays near 100% even when the link availability is somewhat reduced. Herein lies the main issue regarding the strange behaviour of the results for expiration times 5 and 25 seconds.
A fast retransmission timer causes many retransmissions if bundles are hav-
ing trouble getting through to their destination. Some retransmissions are ob-
viously needed, for such cases where a bundle actually has been lost. However,
4.2. SIMULATION RESULTS 19
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Delivery ratio (%)
Link availability (%) Expiry 1 s Expiry 5 s Expiry 25 s Expiry 100 s
Figure 4.5: Delivery ratio with retransmis- sion timer 0.5 seconds, varying link avail- ability
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Delivery ratio (%)
Link availability (%) Expiry 1 s Expiry 5 s Expiry 25 s Expiry 100 s
Figure 4.6: Delivery ratio with retransmis- sion timer 5 seconds, varying link availabil- ity
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Delivery ratio (%)
Link availability (%) Expiry 1 s Expiry 5 s Expiry 25 s Expiry 100 s Expiry 5000 s
Figure 4.7: Delivery ratio with retransmis- sion timer 50 seconds, varying link avail- ability
0 10 20 30 40 50 60 70 80 90 100
0 2000 4000 6000 8000 10000
Delivery ratio (%)
Load (bytes/s) Expiry 1 s
Expiry 5 s Expiry 25 s Expiry 100 s
Figure 4.8: Delivery ratio with retransmis- sion timer 5 seconds, varying load
a bundle can incorrectly be assumed to be lost because of custody acknowl- edgements not getting through in time, for instance when a low link availability causes longer delay. This can trigger a lot of unnecessary retransmissions, caus- ing a lot of waste of network resources.
Figure 4.8 shows how further increasing the data load affects the delivery ratio. For low expiration times the network cannot handle much additional load before the delivery ratio drops drastically.
The retransmissions being too fast can cause a congestion-like state in the network. This in combination with low expiration times causes bundles being delayed for so long that they expire.
Going back to the curves for expiration times 5 and 25 seconds, the ideas presented above apply for these too. With low expiration times and quick retransmissions the network is unable to handle all the data, resulting in poor delivery ratios, even lower than without retransmissions, as any additional data sent causes more delay.
Also when looking at bundles with expiration time 100 seconds, the delivery ratio improves with higher retransmission timers. As the expiration time is higher there is obviously a better chance for bundles to get through in time.
Bundles that never expire, represented in figure 4.7 by expiration time 5 000
seconds, results of course in lossless delivery.
20
Chapter 5
Conclusions
5.1 The bundling protocol
The DTN architecture and the bundling protocol provides a theoretically sound structure for reliable transfers over unreliable networks. More work on the specifications is however needed before the bundling protocol can be widely deployed.
5.1.1 Internet drafts
As the bundling protocol is under development, the specifications have changed noticeably during the work on this thesis. Earlier versions were some- what incomplete and specifications on certain features were missing, but the protocol is getting more mature. With the release of the third version of the bundling protocol, specifications and solutions have been polished and improved.
5.1.2 Applications
Not all applications can be used in a DTN network. Any application that wishes to communicate over a DTN network needs to be able to cope with large delays. This excludes use of interactive applications, real time chatting and surfing the Web from a DTN network. To get access to web pages a different model is required, using special gateways that fetch new information on a regular basis and push it towards the application.
Most applications that only uses one-way communication can be adapted for use in a DTN network, as long as the data they send is still useful after any delays in the network.
5.1.3 Registrations
Before receiving any data, an application needs to register to a DTN agent an endpoint ID to which it expect to receive the data. It is however not defined what action to take on bundles destined for an endpoint ID that never has been registered.
The best way to handle an incoming bundle for an endpoint ID that never has been registered is probably to discard it. Either the application simply has
21
22 CHAPTER 5. CONCLUSIONS
forgotten to register the endpoint ID, but there is no way of knowing that it will ever make a registration, or the node can be subject to a denial-of-service attack.
5.1.4 Security
The security functions need to be specified in more detail to ensure that all implementations share the same security setup.
Security is most important in a network with limited and expensive network resources and must have protection against abuse. One thing that could be verified when handling bundles is that the creation time stamp of a bundle is not too far into the future.
A time stamp in the future or too far into the past indicates that a node has an incorrect clock, but it can also mean that someone is trying to inject unauthorised data.
5.2 DTN implementation
As mentioned previously, it is not possible to use the DTN1 implementation for any meaningful purpose. There is however a reworked version of the DTN implementation, called DTN2[12]. This version is said to be more sound and contain more features than DTN1, but it was released after the testing phase was completed and could not be included in this thesis.
5.3 Simulation model
The simulation model has basically all the functionality defined by the bun- dle protocol specification[2]. A basic routing algorithm and retransmission han- dling has been added, but security functions have been omitted because they are only briefly mentioned in the specification.
The fact that security functions are missing is not a big problem, as security is not a vital part in a test network. This means however that all aspects of the protocol can not be tested, but the model can be extended with this functionality later on.
The implementation of the simulation model provides a good basis for fur- ther development and testing of various functionalities because of the model’s modular design.
The simulations have shown that with certain configurations the model does not behave as desired and shows a strange behaviour. There are also perfor- mance issues causing some simulations to run very slowly. Most of the problems with the simulations are related to network overload, which poses problems to real networks too. There are several things to consider when trying to minimise these problems.
In the current simulation model any node can hold more than one copy of a bundle because of the possibility of network loops. This also means that there is a possibility of bundles being retransmitted more than what is necessary.
This is a design choice made to make sure that bundles are not lost uninten-
tionally. If only one copy of each bundle is allowed, a loop can cause involved
nodes to incorrectly assume that other nodes have custody and release their
5.3. SIMULATION MODEL 23
own, meaning that the bundle is lost. Allowing multiple copies of a bundle in- creases the load on the network, but to avoid reducing delivery ratio it is better to have too many copies of a bundle present than none at all.
There are also problems when using custodial transfer, both with retrans- missions being scheduled too closely and expiration times being set too low.
Another issue concerns status reports, as they can contain vital information but risk being held up by other traffic.
5.3.1 Routing
The main issue when dealing with routing in a network with multiple paths is that network loops can be created. This can cause information to stay in the network until it expires, wasting network resources. The bundling protocol currently has no protection against network loops, but there are some ideas on how to prevent bundles from looping.
Instead of only remembering which node sent a bundle to the current node, it could be beneficial to have a back-trace of the previous nodes that handled the bundle. This information would help preventing loops in a better way than the current method of just waiting a while longer before returning the bundle to the previous node.
Another idea is to have each node remember all bundles they have processed, allowing a node to defer forwarding of a bundle if it just before has passed through. This approach does not require any changes to the bundle headers;
instead a delay for forwarding a bundle a second time is added, analogous to the delay added when sending bundles back to where they came from.
It is not a good solution to use static routing, as simulations only can run on fixed networks and roaming nodes can not be simulated. In addition to including protection against loops, the routing algorithm should be replaced by an algorithm that is adaptable to different network environments.
5.3.2 Custodial transfer
Custodial transfer is theoretically a good feature for dealing with link distur- bances, as it provides reliable transmission without the need of retransmissions from the original node if data is lost.
As shown in the simulations, there is however a larger end-to-end delay for bundles using custodial transfer. As more data is sent over the network, there is also a larger risk for congestion.
On the upside, the delivery ratio of bundles is higher. Theoretically the ratio should be 100%, but as the end-to-end delay increases so does the risk of bundles expiring, thus lowering the delivery ratio. This however only affects bundles with relatively low expiration times. A bundle with an expiration time set much higher than the average end-to-end delay should always reach its destination.
There is however no point in setting the expiration time of custody acknowl- edgements too high. After a bundle has expired, there is no need to send any related custody acknowledgements. Therefore, the expiration time of custody acknowledgements could be set to the time the related bundle has left to live.
This reduces unnecessary retransmissions of the acknowledgements.
As the simulation model allows more than one copy of a bundle at any time,
a network faces the risk of being overloaded because of the additional data.
24 CHAPTER 5. CONCLUSIONS
One thing that would reduce this risk is to defer forwarding of a bundle until the previous node has acknowledged that the current node has custody. This ensures that only one node considers itself to be custodian for the bundle at any time. Another way could be that a node only accepts custody for a bundle one time, and if the bundle loops back the node only forwards it.
5.3.2.1 Retransmissions
Besides choosing an optimal bundle expiration time, the value of the retrans- mission timer is also important to avoid problems when using custodial transfer.
If a static retransmission timer is used, it needs to be higher than the maxi- mum round-trip-time to avoid unnecessary retransmissions. On the other hand, a retransmission timer should never be set higher than the bundle expiration time, as it would result in bundles expiring before ever having a chance to be retransmitted.
Having a fixed retransmission timer is however not a good way of handling retransmissions. Instead, every node should dynamically adjust its timer some- how.
This can be based on local buffer usage, but that would not work when only one end of a link is congested. To improve this, a new report type could be added. It would be used to send current buffer usage to other nodes as a type of flow control messages, but that would increase the load on an already overloaded network.
Another solution would be to measure the time it takes to receive custody acknowledgements and use the mean to calculate the current retransmission timer. This way any node should be able to adjust to any changes before a link gets too heavily congested.
5.3.3 Status reports
The simulation model sets the priority of status reports, including custody acknowledgements, to the same value as of the bundle generating them. It could however be a good idea to prioritise status reports, especially custody acknowledgements, over ordinary bundles. As status reports can be used to monitor the network flow, it is important that they are not delayed for too long time.
If an overloaded network, or any other disturbance causes a custody acknowl- edgement to not get through in time, a retransmission of the related bundle is triggered. Basically every time a bundle is retransmitted because of this, the retransmission is unnecessary and causes additional load on the network.
Setting the priority of custody acknowledgements higher than of other bun- dles would make it easier for them to get through a network, possibly preventing unnecessary retransmissions of bundles and consecutively lowering the load.
5.3.4 Future work
The biggest feature missing in the implementation of the simulation model is
handling of bundle authenticity and security. For a complete simulation model
able to handle everything in the bundle specification, this functionality needs
to be added.
5.3. SIMULATION MODEL 25
Some of the implemented features should be improved. For better handling of retransmissions, the static retransmission timer should be replaced by a dy- namic solution. Also the routing algorithm should be changed to one that can handle dynamic routing, to get support for simulations using mobile nodes.
The simulation model enforces strict priority, meaning that bundles with higher priority always are sent before others. This is mentioned in the specifi- cation as possibly bad, as starvation of lower prioritised bundles can occur. A better solution can be implemented, allowing bundles that have waited for some time to get sent before higher prioritised new bundles.
Although the main parts of the bundling protocol have been developed thor-
oughly, more work is needed on some components and many of the herein pro-
posed changes of both the simulation model and the protocol open up for further
research and studies.
26
Bibliography
[1] V. Cerf et al. Delay-tolerant network architecture. Internet draft, July 2004. http://www.dtnrg.org/docs/specs/draft-irtf-dtnrg-arch-02.txt.
[2] K. Scott and S. Burleigh. Bundle protocol specification. Internet draft, September 2004.
http://www.dtnrg.org/docs/specs/draft-irtf-dtnrg-bundle-spec-02.txt.
[3] Forrest Warthman. Delay-tolerant networks (DTNs): A tutorial v1.1, Mar 2003.
[4] S. Jain, K. Fall, and R. Patra. Routing in a delay tolerant network.
SIGCOMM, Aug/Sep 2004.
[5] Anders Lindgren, Avri Doria, and Olov Schelén. Probabilistic routing in intermittently connected networks. In Proceedings of The First
International Workshop on Service Assurance with Partial and Intermittent Resources (SAPIR 2004), August 2004.
[6] S. Burleigh et al. Licklider transmission protocol. Internet draft, July 2004. http://www.dtnrg.org/docs/specs/draft-irtf-dtnrg-ltp-01.txt.
[7] K. Fall, W. Hong, and S. Madden. Custody transfer for reliable delivery in delay tolerant networks. Intel Research, IRB-TR-03-030, July 2003.
[8] IPN special interest group, April 2005. http://www.ipnsig.org.
[9] Delay tolerant networking research group, April 2005.
http://www.dtnrg.org.
[10] Sámi network connectivity project, April 2005.
http://www.snc.sapmi.net.
[11] Robert C. Durst. Delay-tolerant networking: An example interplanetary internet bundle transfer. Internet draft, March 2003. http://
www.dtnrg.org/specs/OLD/draft-irtf-dtnrg-ipn-bundle-xfer-00.txt.
[12] Dtn reference implementation, April 2005.
http://www.dtnrg.org/wiki/Code/.
[13] Ns-2 network simulator, April 2005. http://www.isi.edu/nsnam/ns/.
[14] Nam network animator, April 2005. http://www.isi.edu/nsnam/nam/.
27
28 BIBLIOGRAPHY
[15] Statistics::pointestimation, April 2005. http://search.cpan.org/∼yunfang/
Statistics-TTest-1.1.0/PointEstimation.pm.
[16] Gnuplot, April 2005. http://www.gnuplot.info.
Appendix A
User guide
A.1 Introduction
This describes the usage of the implemented simulation model. The source code is available on http://www.illuvatar.nu/ns-dtn/.
A.2 Node command interface
These commands are used to control most aspects of the simulation model’s behaviour.
A.2.1 Setup
The setup commands should not be used after the simulation has started.
A.2.1.1 Add routing entry
Adds a new route to the routing table. The command is also used to define the MTU of a link.
add route nexthop custodian metric mtu
route Region accessible through this link. Use * to indicate a default route.
nexthop Address of the node the bundles should be forwarded to.
custodian 1 if next node is known as a custodian. 0 otherwise.
metric Metric or priority of the link.
mtu MTU of the link.
A.2.1.2 Set region
Sets the current region of the node.
region region
region The region that the node belongs to.
29
30 APPENDIX A. USER GUIDE
A.2.2 Runtime
The runtime commands can be used as timed events to control the behaviour of the actual simulation.
A.2.2.1 Send request
Send is used to send new bundles to other nodes and applications.
send sid did rid cos options ls binding adu dsize sid Source endpoint ID. region,node:app.
did Destination endpoint ID. region,node:app.
rid Report-to endpoint ID. region,node:app.
cos Class of service, or priority. BULK, NORMAL or EXPEDITED.
options Delivery options. Separated by “,” but no spaces.
NONE No options. The use of this option cancels all other options.
CUST Request custodial transfer.
EERCPT Request end-to-end return receipt.
REPRCPT Request bundle reception reporting.
REPFWD Request bundle forwarding reporting.
REPCUST Request bundle custody transfer reporting.
PSAUTH Activate bundle authentication.
1PSINT Activate bundle integrity.
1PSENC Activate Bundle encryption.
1ls Lifespan; time in whole seconds that the bundle is valid and still should be delivered.
binding Send token binding.
adu Application data unit. A global TCL variable containing a message to send.
dsize Size of data. It can be used to create large packets without having to create large application data units. If dsize is less than the actual length of adu the size will be adjusted to that of the actual data.
A.2.2.2 Cancel bundle request
Cancel tries to stop the bundle from being sent. It only acts locally, which means that if the bundle has already been sent no action will be taken.
cancel sendtoken
sendtoken The token returned by the sendtoken callback function, specifying which bundle to cancel.
1
Not supported.
A.2. NODE COMMAND INTERFACE 31
A.2.2.3 Register request
Registers a destination to allow reception of bundles.
register dfa binding did
dfa Delivery failure action. Defines how received bundles are treated when the application is not in active receive mode.
DEFER Received bundles are stored for later delivery.
ABORT Received bundles are dropped without accepting them. This is the default action.
SINK Received bundles are accepted and then dropped. This is used in the simulations to get a silent target.
2binding Registration token binding.
did Destination endpoint ID.
A.2.2.4 Start delivery request
Enables passive reception of bundles. After issuing this command bundles are delivered automatically to the application as soon as they are received.
start_delivery regtoken
regtoken The token returned by the registrationtoken callback function.
A.2.2.5 Stop delivery request
Disables passive reception of bundles. After issuing this command bundles will not be delivered automatically, but will instead be handled as specified by the delivery failure action.
stop_delivery regtoken
regtoken The token returned by the registrationtoken callback function.
A.2.2.6 Change registration request
Updates the registration with a new delivery failure action.
change_registration regtoken dfa
regtoken The token returned by the registrationtoken callback function.
dfa Delivery failure action. Defines how received bundles are treated when the application is not in active receive mode.
DEFER Received bundles are stored for later delivery.
ABORT Received bundles are dropped without accepting them. This is the default action.
SINK Received bundles are accepted and then dropped. This is used in the simulations to get a silent target.
22
Not included in the protocol specification
32 APPENDIX A. USER GUIDE
A.2.2.7 Poll request
Requests delivery of one bundle for the specified endpoint ID.
poll did
did Destination endpoint ID.
A.2.2.8 Application interface
The application interface is used to specify DTN specific settings for an ns-2 application connected to the DTN agent.
app var value
Where var is one of the following src Source endpoint ID. region,node:app.
dest Destination endpoint ID. region,node:app.
rpt_to Report-to endpoint ID. region,node:app.
cos Class of service, or priority. BULK, NORMAL or EXPEDITED.
options Delivery options. Separated by “,” but no spaces.
NONE No options. The use of this option cancels all other options.
CUST Request custodial transfer.
EERCPT Request end-to-end return receipt.
REPRCPT Request bundle reception reporting.
REPFWD Request bundle forwarding reporting.
REPCUST Request bundle custody transfer reporting.
PSAUTH Activate bundle authentication.
3PSINT Activate bundle integrity.
3PSENC Activate Bundle encryption.
3lifespan Time in whole seconds that the bundle is valid and still should be delivered.
A.2.3 Callback functions
The callback functions are TCL functions that must be provided by the simulation TCL script. They are used to inform about events and to report assigned tokens to the different bindings.
3
