© 2005 The MITRE Corporation. Intel Berkeley Research Lab. All rights reserved The DTNRG: Where are we? R. Durst – The MITRE Corporation K. Fall – DTNRG Chair, Intel Research, Berkeley M. Demmer – University of California, Berkeley/Intel K. Scott – The MITRE Corporation S. Burleigh – NASA/Jet Propulsion Laboratory 9 March 2005 Excerpted from: DARPA Disruption Tolerant Networking Kickoff Meeting

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved DTN challenges… n Intermittent/Scheduled/Opportunistic Links –Scheduled transfers can save power and help congestion; scheduling common for esoteric links n Interrupted Links –RF noise, light or acoustic interference, LPI/LPD concerns –Frequent disconnection among mobile nodes due to terrain/fading n Very Large Delays –Natural prop delay could be seconds to minutes –If disconnected, may be (effectively) much longer n Different Network Architectures –Many specialized networks won’t/can’t ever run IP

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Delay-Tolerant Networking Architecture n Goals –Support interoperability across ‘radically heterogeneous’ networks –Acceptable performance in high loss/delay/error/disconnected environments –Decent performance for low loss/delay/errors n Components –Flexible naming scheme with late binding –Message overlay abstraction and API –Routing and link/contact scheduling w/CoS –Per-(overlay)-hop reliability and authentication

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Background n IETF/IRTF DTNRG formed end of 2002 –See n DTN1 Agent Source code released 3/2003 n DTN2 Agent Source code released 12/2004 and 3/2005 n SIGCOMM Papers: 2003 [arch], 2004 [routing] n Several other documents (currently ID’s): –DTNRG Architecture document –Bundle specification –Application of DTN in the IPN

© 2005 The MITRE Corporation. Intel Berkeley Research Lab. All rights reserved Perspective

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Perspective: Where do we think we are with all of this? n Scope: –The Architecture Document and associated protocols n Considerations: –Things we’re pretty sure about –Things we think are good ideas –Things we believe need refinement –Things that are totally open

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that we’re pretty sure about in the Architecture Document n Message-oriented abstraction –But messages can be short (100 bits) –Some pressure to support streaming n Store and forward operation with Custodial transfers (advancing the point of retransmission toward the destination) n Network of internets n Postal-like COS: Relative priorities and basic notifications n Synchronized time (to some degree) and time-based message purge n Fragmentation (proactive and reactive) n Two-part endpoint identifiers (region, admin; admins opaque outside region; eventual reachability within a region) n Taxonomy of contacts

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things we think are good ideas n Architecture Document: –Security focus on infrastructure protection –Persistent, asynchronous application registration –In-network persistent storage traded for end-to-end retransmission –Maintenance of routing state across network partitioning

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that probably need refinement n Architecture document –Use of bundle expiration time as (sole) mechanism for routing loop recovery n Must be reconciled with intentional replication for robustness n Recent discussion of a bundle node in the network adding an optional header analogous to a VIA field to identify loops, etc. May need more than one of these fields n Is this better than a replay cache? –Using multipath routing & forwarding to improve reliability/ decrease latency n How to remove duplicates once we decide they’re no longer needed? –Endpoint identifiers: What is the relation between administrative identifiers across regions? Is there constancy that can be assumed? In what circumstances? –Congestion and flow control (utility of economic models?) –Ability to use forward erasure coding in conjunction with multipath routing / forwarding –How and when to trust assertions of security made by lower layers

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that are totally open n Architecture document –Network startup and bootstrapping –Resource discovery (e.g. multicast session information, –Authentication mechanisms: PKI, IBC, other? –What are regions? Do they have topological significance? Are they simply namespace identifiers? n What routing architectures are preferable? Flat? Single level hierarchy? Multi-level? Overlapping? n Do nodes move among regions? What are the dynamics of inter- region mobility? Is an additional, topology-independent identifier space necessary? n What benefits accrue from late binding when regions do not have topological significance? –Policy issues

© 2005 The MITRE Corporation. Intel Berkeley Research Lab. All rights reserved The Protocols

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that we’re pretty sure about in the Bundle Protocol spec n Service Primitives (§2.5) –E.g., send, register, start/stop delivery, poll, change/end registration n Header Chaining Structure (§3.1) n Administrative Payloads (§5) –Application data where the bundle node is the application, and the data units support the operation of the bundle protocol itself –Bundle status payloads, Custody ACKs, etc. n Split of responsibilities between bundle & convergence layers (§6)

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that we’re pretty sure about in the LTP protocol spec n LTP spec: –Most of the concepts inherited from CFDP: n Transaction/session model versus stream model) n Use of non-volatile storage for both state and data n Absence of negotiation n Laconic acknowledgement n Adjacency (point-to-point as opposed to end-to-end n Lives under a network and above a [functional] link) n Deferred transmission. –Protocol features that are intended to fix problems in CFDP: n Reducing the number of different protocol data unit types n Replacing the periodic retransmission of NAKs with reciprocal acknowledgements –Protocol extension mechanism

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things we think are good ideas n Bundle Protocol Spec: –Dictionary to improve header overhead (§3.8) n Pointers in primary bundle header currently assume two-part naming –Supporting indirect transfers n Alternatives include DHTs, FTP-passive-mode-like rendezvous n LTP Spec: –Partial reliability –Timeout interval computation –Accelerated retransmission

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that probably need refinement n Bundle protocol spec –API required to implement security architecture –Protocol support for multipoint delivery

© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved Things that are totally open n Bundle Protocol Spec: –Interaction between user desires and policy n API for notification / negotiation –Protocol support for streaming apps?