We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJulissa Grass
Modified over 4 years ago
© 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 http://www.dtnrg.org 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?
Dynamic Source Routing (DSR) algorithm is simple and best suited for high mobility nodes in wireless ad hoc networks. Due to high mobility in ad-hoc network,
Communication Topics Jason Hill –
Using Network Virtualization Techniques for Scalable Routing Nick Feamster, Georgia Tech Lixin Gao, UMass Amherst Jennifer Rexford, Princeton University.
Presenter: Anika Aziz National Institute of Informatics (NII), The Graduate University for Advanced Studies, Tokyo, Japan.
Delay Tolerance in a Network of Information Dirk Kutscher – NEC Labs SAIL Project Consortium DTNRG IETF
1 Improving TCP Performance over Mobile Networks HALA ELAARAG Stetson University Speaker : Aron ACM Computing Surveys 2002.
Doc.: IEEE /243r0 Submission March 2002 James Kempf, DoCoMo LabsSlide and IP James Kempf Seamoby WG Co-chair DoCoMo Labs USA
National Aeronautics and Space Administration 1 Licklider Transmission Protocol (LTP): An Overview Scott Burleigh Jet Propulsion Laboratory California.
COS 461 Fall 1997 Routing COS 461 Fall 1997 Typical Structure.
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed System Architectures.
Group #1: Protocols for Wireless Mobile Environments.
1 Chapter 3 TCP and IP. Chapter 3 TCP and IP 2 Introduction Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) User Datagram Protocol.
1 Observations regarding a new architecture Kevin Fall Intel Research, Berkeley 18-Sep-2006, Cambridge, UK.
© 2004 The MITRE Corporation. All rights reserved DTN Security Susan Symington March 2005 IETF DTN meeting.
CSE University of Washington Multipath Routing Protocols in AdHoc Networks.
Multicasting in Mobile Ad-Hoc Networks (MANET)
S. Burleigh, A. Hoke, L. Torgerson, K. Fall, V. Cerf, B. Durst, K. Scott, H. Weiss An approach to Interplanetary Internet Presented by Fabián E. Bustamante.
DTNs Delay Tolerant Networks. Fall, Kevin. Intel Research, Berkeley. SIGCOMM 2003 Aug25, A Delay- Tolerant Network Architecture for Challenged Internets.
1-1 CMPE 259 Sensor Networks Katia Obraczka Winter 2005 Transport Protocols.
Department of Computer Science, Purdue University Active Networks: Applications, Security, Safety and Architectures Author: Konstantinos Psounis Stanford.
© 2018 SlidePlayer.com Inc. All rights reserved.