Transcript DTNRG: Where are we?

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…




Intermittent/Scheduled/Opportunistic Links
– Scheduled transfers can save power and help
congestion; scheduling common for esoteric links
Interrupted Links
– RF noise, light or acoustic interference, LPI/LPD
concerns
– Frequent disconnection among mobile nodes due to
terrain/fading
Very Large Delays
– Natural prop delay could be seconds to minutes
– If disconnected, may be (effectively) much longer
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

Goals
– Support interoperability across ‘radically
heterogeneous’ networks
– Acceptable performance in high
loss/delay/error/disconnected environments
– Decent performance for low loss/delay/errors

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

IETF/IRTF DTNRG formed end of 2002
– See http://www.dtnrg.org




DTN1 Agent Source code released 3/2003
DTN2 Agent Source code released 12/2004 and 3/2005
SIGCOMM Papers: 2003 [arch], 2004 [routing]
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?

Scope:
– The Architecture Document and associated protocols

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

Message-oriented abstraction
– But messages can be short (100 bits)
– Some pressure to support streaming







Store and forward operation with Custodial transfers
(advancing the point of retransmission toward the
destination)
Network of internets
Postal-like COS: Relative priorities and basic notifications
Synchronized time (to some degree) and time-based
message purge
Fragmentation (proactive and reactive)
Two-part endpoint identifiers (region, admin; admins
opaque outside region; eventual reachability within a
region)
Taxonomy of contacts
© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved
Things we think are good ideas

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

Architecture document
– Use of bundle expiration time as (sole) mechanism for routing loop
recovery

Must be reconciled with intentional replication for robustness

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

Is this better than a replay cache?
– Using multipath routing & forwarding to improve reliability/ decrease
latency

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

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?

What routing architectures are preferable? Flat? Single level
hierarchy? Multi-level? Overlapping?

Do nodes move among regions? What are the dynamics of interregion mobility? Is an additional, topology-independent identifier
space necessary?

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

Service Primitives (§2.5)
– E.g., send, register, start/stop delivery, poll, change/end
registration


Header Chaining Structure (§3.1)
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.

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

LTP spec:
– Most of the concepts inherited from CFDP:

Transaction/session model versus stream model)

Use of non-volatile storage for both state and data

Absence of negotiation

Laconic acknowledgement

Adjacency (point-to-point as opposed to end-to-end

Lives under a network and above a [functional] link)

Deferred transmission.
– Protocol features that are intended to fix problems in CFDP:

Reducing the number of different protocol data unit types

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

Bundle Protocol Spec:
– Dictionary to improve header overhead (§3.8)

Pointers in primary bundle header currently assume two-part
naming
– Supporting indirect transfers


Alternatives include DHTs, FTP-passive-mode-like rendezvous
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

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

Bundle Protocol Spec:
– Interaction between user desires and policy

API for notification / negotiation
– Protocol support for streaming apps?
© 2005 The MITRE Corporation, Intel Berkeley Research Lab. All rights reserved