Delay Tolerant Networking Gareth Ferneyhough UNR CSE Department

Overview Introduction Why DTN? Overview of DTN protocol Current issues Conclusion

Introduction The internet is awesome. Provides reliable data delivery with little effort by the end user. However, some assumptions on the network structure (uptime, physical medium, latency). We want to extend this to “challenged networks”

Normal vs. challenged network

Challenged networks: Terrestrial mobile networks Military ad-hoc networks Sensor node networks Exotic media networks – (satellite communication) These networks may experience the following: High latency/low data rate Disconnection Long queuing times Interoperability considerations Low power requirements Current transport layers cannot handle communication to and between challenged networks.

Why DTN? Some current (not so great) solutions: – Link repair Performance enhancing proxies Protocol boosters These “fool” the end stations by actively modifying end to end data stream Problems: breaking internet principles – complexity in the middle, maintaining state, etc. Protocol boosters are specific; unable to use them in different applications. It would be more ideal to provide standard protocols which provide communication to and through challenged networks.

DTN! Proposed solution: delay tolerant networking architecture Provide a network architecture independent messaging service. Operates above transport layer for various network architectures and provides store and forward functionality for dissimilar and special networks. DTN required to store messages in non-volatile memory when reliable delivery is required. DTN provides name-mapping via globally unique tuples.

DTN used for Mars rover communication

DTN Naming {region name, entity name} {internet.earth, {R1.cjuj.AlphaCentari, #Roys-ipad#} global identifiers can be statically added entries, or resolved through a hierarchy similar to DNS.

Class of service How to provide different classes of service without unnecessary complexity to the end user? Postal Service analogy: – low, ordinary, high priority – notification of mailing – notification of delivery – route taken – careful handling (reliable delivery)

Path selection Contacts parameterized by: – Start and end times – latency – Direction – capacity. End to end routing path cannot be assumed. Instead, routes are classified as a cascade of time-dependent contacts (communication opportunities).

Custody transfer and security Custody transfer: Message transferred to a DTN note classified as persistent, which has large amounts of non-volatile storage. Can hold the message until the next communication opportunity. Security: Want to avoid carrying unnecessary and unauthorized traffic. Each message contains a “postage stamp” with a verifiable sender, class of service, and other cryptographic material that can quickly verify the messages authenticity. Routers check this at each hop, discarding messages early if authentication fails. This also makes DoS attacks more difficult. Current approach used public key cryptography.

DTN Forwarder

Application interface Applications must be careful not to accept timely responses. In fact, the request/response time may often exceed the longevity of the server and client processes.

Current news Recently ( ) on NASA’s page: The Delay Tolerant Networking (DTN) will test communication protocols with the Commercial Generic Bioprocessing Apparatus (CGBA) onboard the International Space Station that can be used for exploration. The primary purpose of this activity is to rapidly mature the DTN technology for use in NASA's exploration missions and space communications architecture. Source:

Conclusion DTN is a proposed protocol standard which allows interoperability between special and challenged networks with an easy to use API. Currently a hot topic, especially with NASA. References: Fall, K A delay-tolerant network architecture for challenged internets. In Proceedings of the 2003 Conference on Applications, Technologies, Architectures, and Protocols For Computer Communications (Karlsruhe, Germany, August , 2003). SIGCOMM '03. ACM, New York, NY, DOI=