Delay Tolerant Networking (DTN)

DTN, an architecture that is designed for occasioanlly-connected networks, which are expected to suffer from frequent partitions and long delay paths unlike the IP network, is becoming more and more popular amongst challenged networks such as military-based networks that use scheduled connectivity based on priority and limited bandwidth due to hostile environments, terrestrial wireless networks that cannot maintain end-to-end connectivity due to interference and node mobility, exotic networks with moderate delays and periodic connectivity, and sensor and actuator networks with moderate delays, limited memory and CPU capability and frequent interruptions due to environmental factors. In DTN, acknowledgment from the far end is optional and based upon the class of service selected since DTN is primarily used in disconnected states, so it’s not really efficient if used mainly for chatting and direct communication (which is assumed to work best in TCP/IP) especially due to the fact that connections are constantly changing, the source and destination are not always directly connected, and the movements of nodes are unpredictable. Unlike the TCP/IP model, DTN networks rely on high latency and low data rate since it’s not always expected to have a connection, so even if it takes longer (say, two minutes or even days) compared to milliseconds it takes IP, it will be more reliable. It doesn’t really matter when the data gets across the network, as long as it gets there. Now, as to “how” they get across, DTN focuses on bundle switching using regions and gateways. It also uses a naming scheme, which is called name tuples which are late-bonded to emphasize of the flexibility of naming data. Aside from gateways and tuples, DTN also has an interesting concept on how it manages congestion. Congestion occurs when there is too much data and limited space for storing that data, which is tied to flow control since it’s what manages how much data goes in and how much goes out keeping a balance. It can either drop data or even transfer the custody to someone else leaving it up to them to take care of the bundle. There can also be a TTL (time-to-live) which can be managed to effectively decide on how to drop expired data, since DTN’s model is based around contacts, so the newer it is the higher probability it has to be sent to it’s destination; however, since DTN is an overlay model, it will not be able to do overflow, since that falls into the jurisdiction of the underlying architecture.

Leave a Reply

Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar