Back to DtnAgent Home
The DtnAgent is implemented as a subclass of the Agent class and, in a fashion similar to other agents, can be attached to an ns-2 node as well as a source or a sink application. There is a single type of a DtnAgent and it is used for all purposes; as a source agent, a relaying agent, or a destination agent. When the TCP convergence layer is used a special pair of source and sink TCP classes is employed, while when the UDP convergence layer is used a customized UDP class is employed. These classes are named TcpDtnAgent, TcpDtnSink and UdpDtnAgent respectively and, by utilizing a newly introduced DtnHeader, work along with the DtnAgent in facilitating bundle transmission and reception.
Under the TCP convergence layer operation, both the DTN and the transport layers implement fragmentation/segmentation based on the maximum bundle size and the maximum packet size respectively. When the application orders the transmission of a certain amount of data (i.e. an ADU), this data is fragmented based on the maximum bundle size by the DtnAgent. Depending on the maximum bundle size and the amount of data, the whole ADU may be transmitted as a single bundle. The created bundles are passed on to the TcpDtnAgent where they are further segmented, creating the appropriate number of TCP packets. Each TCP packet contains the offset of the original bundle so that duplicate data reception originating from multiple sources can be identified. The TcpDtnAgent increments the packets available for transmission by the number of the newly arrived packets, and appends the corresponding DtnHeader to a list, along with some additional information (i.e. TCP sequence number). When the time comes to actually transmit a certain packet, a helper function retrieves the corresponding DtnHeader from the list and populates the DTN header of the outgoing packet. On the other end of the connection, the TcpDtnSink aggregates in-sequence, incoming data based on the bundle it belongs to, and delivers it along with the bundle header to the attached DtnAgent.
Under the UDP convergence layer operation, each bundle is encapsulated in a single UDP packet, with the packet size being set to the total bundle size (a UDP header is not considered in ns-2). If the bundle size, including the bundle header, is larger than the maximum packet size for UDP, bundle transmission is aborted. Unlike TCP, the UdpDtnAgent does not support flow control and, therefore, data created at the application layer and passed on to the DTN and then to the UDP layer are directly buffered at the next hop link queue. Hence, if a file of 1 MB must be transferred, there must be at least 1 MB of space at the queue of the outgoing link to the next hop, or else part of the data will be dropped at the very node that it was produced.
As of now, routing is implemented in a simplistic way, assuming a convenient rhombus topology. When a source DtnAgent is connected to a destination DtnAgent the destination agent is added to the source agent's downstream (outgoing) connections, while the source agent is added to the destination agent's upstream (incoming) connections. Each connection requires two sets of a TcpDtnAgent and a TcpDtnSink, or two sets of two UdpDtnAgent classes for the UDP convergence layer case, in order to accommodate data bundles in the downstream direction and report bundles in the upstream direction. In a DTN overlay each DtnAgent can have multiple incoming and multiple outgoing connections as long as all outgoing connections ultimately lead to the final destination. The final destination is regarded as the DtnAgent that is attached to a sink application. All other DtnAgents on the path simply forward the incoming bundles on to their outgoing connections in a round-robin fashion, following a cut-through strategy (an incoming packetload of a bundle is immediately passed on to the next downstream TcpDtnAgent or UdpDtnAgent). Along these lines, alternative mechanisms of outgoing connection selection as well as non cut-through routing (a bundle is fully received before being forwarded) can be easily realized.
The DtnAgent implements a simple custody acceptance/rejection and retransmission mechanism, targeted mainly towards accommodating certain experimental scenarios. However, other schemes can be readily implemented and incorporated into the existing code. Each DtnAgent is assumed to have a certain amount of available storage space. When the first bytes of a new bundle arrive (i.e. those that contain the bundle header in a real-world situation), the agent checks if accepting the bundle will exceed the available storage space. In this case it initiates a custody rejection report to the upstream agent and rejects subsequent bytes belonging to the same bundle. If adequate storage space is available, the bundle is accepted along with all subsequent bytes that belong to it. When a bundle is fully received the DtnAgent issues a custody acceptance report targeted to the upstream node. At the reception of a custody acceptance the upstream node removes the corresponding bundle from storage. Partially received bundles are considered as placeholders and assumed to occupy the full bundle size, so that once a bundle is accepted there is guaranteed enough space for it to be fully received.
The DtnAgent implements a basic retransmission mechanism in order to ensure that custody for a bundle has been successfully transferred. In the TCP convergence layer case no action relative to the retransmission timer is taken the instant when a bundle is added to the TcpDtnAgent queue. Instead, the TcpDtnAgent notifies the DtnAgent through a callback function when the last part of a queued bundle has been actually transmitted and a retransmission timer is then started. In the UDP convergence layer case the timer is set as soon at the bundle is added to the link queue. The DtnAgent ensures that the retransmission timer is always set to the earlier retransmission time of the stored bundles. Reception of a custody rejection for a certain bundle resets its retransmission time, while reception of a custody acceptance updates the retransmission timer in case the relevant bundle was the earliest bundle pending for retransmission. In both cases, when TCP is employed, the downstream TcpDtnAgent is notified in order to remove data related to the reported bundle from its queue (so as to avoid redundant data transmission). When UDP is employed, the in-flight bundles are already in the link queue and, therefore, transmission cannot be aborted.
Currently, the retransmission timeout is set by the user to a constant value. However, sophisticated timeout calculation mechanisms can be easily fitted into the model. If the timeout value is set to 0, then no retransmissions occur whatsoever. Instead, a bundle is removed from storage as soon as it either finishes transmitting or a custody rejection report arrives for it. Possible pending transmission for the removed bundle is canceled.
Additionally to the basic functionality described so far, the DTN model is equipped with a rendezvous (RV) mechanism, whose goal is to improve energy efficiency on mobile networking devices. The RV mechanism is employed at the last hop (wireless connection) of a data transfer originated from some wired node and targeted to a mobile device on a 802.11 WLAN. In such a scenario, minimal DTN deployment involves attaching DtnAgents at the source node, the Base Station (BS) and the destination (mobile node). Incoming data is buffered at the DtnAgent attached to the BS and flushed at certain RV times, allowing the receiver to switch its wireless interface to the sleep state in the meantime. At RV time the BS fragments bundles that have been partially received during the previous idle period and sends them on the wireless link. Meanwhile, bytes belonging to the original unfragmented bundle (which can be a fragment of another bundle itself) are still being received by the BS from the upstream node. The RV mechanism can only be employed along with TCP as the convergence layer.
Even though the RV mechanism is a feature designed to test a particular research proposition, the dynamic fragmentation of bundles (very similar to reactive fragmentation) can be useful in a variety of scenarios. For instance, DTN nodes can dynamically fragment bundles in a way that balances storage space occupation over the network. Fragment size can even be negotiated with the downstream node in cases storage space is very limited.
