imported>Trustable: Trustable verschob die Seite Delay-Tolerant Networking nach Delay-tolerant Networking: Analog zu Any-source Multicast

2026-04-07T23:46:28Z

Trustable verschob die Seite Delay-Tolerant Networking nach Delay-tolerant Networking: Analog zu Any-source Multicast

Neue Seite

[[Datei:Delay-Disruption Tolerant Networking (DTN).webm|mini|thumbtime=66|Vergleich zwischen traditionellem IP-Protokoll und Delay-Tolerant Networking]]
Das '''Delay-Tolerant Networking''' (englisch für ''verzögerungstolerantes Netzwerk''; auch ''{{lang|en|Disruption-Tolerant Networking}}'', für ''unterbrechungstolerantes Netzwerk'', und kurz ''{{lang|en|DTN}}'' genannt) ist eine Protokollarchitektur zur Überwindung der technischen Schwierigkeiten spärlich verbundener und heterogener Kommunikationsnetzwerke. Die Architektur basiert auf dem von der US-amerikanischen Raumfahrtbehörde ''[[National Aeronautics and Space Administration|NASA]]'' entwickelten ''[[Interplanetares Internet|interplanetaren Internet]]'' (IPN), generalisiert diesen Entwurf jedoch. Im Gegensatz zum Entwurfsschwerpunkt des IPN – die Weltraumkommunikation – fokussiert das DTN auf Netzwerke mit geringer Stabilität der Ende-zu-Ende-Verbindung.

== Entwicklung ==
Etwa gleichzeitig mit der Entwicklung mobiler Ad-hoc-Routingverfahren beauftragte die [[Defense Advanced Research Projects Agency|DARPA]] in den 1990er Jahren unabhängig davon die NASA, ''[[Mitre Corporation|MITRE]]'' und andere, einen Vorschlag für ein ''[[Interplanetares Internet]]'' (IPN) zu erarbeiten. Ein grundlegender Entwurf für eine IPN-Architektur wurde von einer Gruppe um [[Vint Cerf]] unter Berücksichtigung der Störungsanfälligkeit der Netzwerkverbindungen (Packet Corruption) im All und der notwendigen Behandlung langer Nachrichtenlaufzeiten (Packet Delay) vorgelegt.

Im Jahr 2002 nahm [[Kevin Fall]] einige dieser Ideen für die Entwicklung eines allgemein unterbrechungstoleranten Netzwerks auf und stellte seinen Entwurf 2003 unter dem Titel ''Delay Tolerant Networking'' und dem sich daraus ableitenden Akronym DTN auf der [[SIGCOMM]]-Konferenz vor.<ref>[http://conferences.sigcomm.org/sigcomm/2003/papers.html#p27-fall A Delay-Tolerant Network Architecture for Challenged Internets], K. Fall, SIGCOMM, August 2003</ref> In den Folgejahren wurden die Voraussetzungen für ein entsprechendes Netzwerk auf verschiedenen Konferenzen besprochen, das auch mit langen Signallaufzeiten und Verbindungsunterbrechungen umgehen kann. Dabei sollten auch die Erfahrungen mit Sensornetzwerken und mobilen Ad-hoc-Routingverfahren berücksichtigt werden. Die Routingalgorithmen und Verfahren zur Sicherstellung der Verlässlichkeit und Überprüfbarkeit der übermittelten Daten konnten im Laufe der Zeit verbessert werden.

Im Januar 2017 versendeten Forscher der [[McMurdo-Station]] in der [[Antarktis]] ein Selfie mit Hilfe des DTN-Protokolls.<ref>{{Internetquelle |autor=Erin Mahoney |url=http://www.nasa.gov/feature/antarctic-selfie-s-journey-to-space-via-disruption-tolerant-networking |titel=Antarctic Selfie’s Journey to Space via Disruption Tolerant Networking |datum=2017-11-27 |abruf=2020-01-20}}</ref>

== Routing ==
Die Übermittlung und das Routing der zu übermittelnden Informationen von der Datenquelle bis zum Ziel sind eine grundlegende Notwendigkeit in allen Datennetzen. Dabei unterscheiden sich DTNs in erster Linie durch die fehlende dauerhafte Verbindung zwischen Datenquelle und Datenziel von anderen Datennetzen. Ad-hoc-Routingverfahren, wie ''[[Ad-hoc On-demand Distance Vector|AODV]]'' und ''[[Dynamic Source Routing|DSR]]'',<ref>{{Literatur |Autor=C. Perkins, E. Royer |Titel=Ad-hoc on-demand distance vector routing |Sammelwerk=The Second IEEE Workshop on Mobile Computing Systems and Applications |Datum=1999}}</ref><ref>{{Literatur |Autor=D. Johnson, D. Maltz |Titel=Dynamic source routing in ad hoc wireless networks |Sammelwerk=Mobile Computing |Verlag=Kluwer Academic |Datum=1996 |Seiten=153–181}}</ref> konnten unter diesen Voraussetzungen nicht eingesetzt werden, weil sie versuchen, erst den vollständigen Weg von der Quelle zum Ziel zu ermitteln und die Daten erst anschließend übermitteln. Wenn eine kontinuierliche Ende-zu-Ende-Kommunikation jedoch nur schwierig oder überhaupt nicht sichergestellt werden kann, ist der Ansatz des ''[[Teilstreckenverfahren|Store and forward]]''-Prinzips sinnvoller. Dabei werden die Daten in kleinen Paketen von einem Netzwerkteilnehmer zum nächst erreichbaren übertragen und jeweils gespeichert, bis die Übertragung zum Zielrechner erfolgreich bestätigt werden konnte.<ref>John Burgess, Brian Gallagher, David Jensen, Brian Neil Levine. MaxProp: ''Routing for vehicle-based disruption-tolerant networks''. In: ''Proc. IEEE INFOCOM'', April 2006.</ref><ref>Philo Juang, Hidekazu Oki, Yong Wang, Margaret Martonosi, Li Shiuan Peh, Daniel Rubenstein: ''Energy-efficient computing for wildlife tracking: design tradeoffs and early experiences with zebranet''. In: ''SIGOPS Oper. Syst. Rev.'', 2002, 36(5), S. 96–107.</ref><ref>Augustin Chaintreau, Pan Hui, Jon Crowcroft, Christophe Diot, Richard Gass, James Scott. ''Impact of human mobility on opportunistic forwarding algorithms. IEEE Transactions on Mobile Computing'', 2007, 6(6), S. 606–620.</ref> Die Übertragung der Nachricht in der gleichen Version auf mehreren Wegen von der Quelle zum Ziel ist ein gängiger Ansatz, um die Wahrscheinlichkeit einer erfolgreichen Nachrichtenübertragung zu erhöhen.<ref>{{Literatur |Autor=Amin Vahdat, David Becker |Hrsg=Duke University |Titel=Epidemic routing for partially connected ad hoc networks |Sammelwerk=Technical Report CS-2000-06 |Datum=2000}}</ref>

=== Bundle-Protokolle ===
Die <nowiki>RFC 4838</nowiki><ref>{{RFC-Internet |RFC=4838 |Titel=Delay-Tolerant Networking Architecture |Datum=2007-04}}</ref> und <nowiki>RFC 5050</nowiki><ref name="RFC5050" /> wurden im Jahr 2007 veröffentlicht, sie liefern eine für die Entwicklung von Algorithmen und Anwendungen notwendige Übersicht über Anforderungen für die in einem DTN eingesetzte Software. Dieses, allgemein als Bundle-Protokoll bezeichnete Protokoll definiert eine Folge von zusammenhängenden Datenblöcken als ein Bündel, dabei enthält jedes Bündel im Gegensatz zu einem individuellen Datenblock ausreichende semantische Informationen, um eine Applikation fortzusetzen. Bündel werden zwischen den an das Netzwerk angeschlossenen [[Netzwerkelement|Knoten]] nach dem ''Store and forward''-Prinzip übertragen, dabei können verschiedene Transportprotokolle verwendet werden, die auf dem [[Internet Protocol]] (IP) basieren können, es aber nicht voraussetzen. Die Protokollebenen, die die Bündel auf ihrem lokalen Netzwerk übertragen, werden als ''bundle convergence layers'' bezeichnet. Die Bundle-Architektur funktioniert wie ein [[Overlay-Netzwerk]], sie nutzt eine zusätzliche Namensarchitektur, die auf [[Endpoint Identifier]]s (EIDs) und auf einer groben [[Class of Service]] Einteilung aufbaut.

Das Bundle-Protokoll muss den unterschiedlichen Bedarf einzelner Anwendungen für das Senden von Bündeln über das Netzwerk ausgleichen. Auf Grund der ''Store and forward''-Natur der DTN-Protokolle profitieren Routing-Lösungen davon, dass Informationen von der Applikationsebene für das Routing bekannt sind. So kann beispielsweise das Netzwerk berücksichtigen, wenn eine Anwendung darauf angewiesen ist, Daten besonders schnell, in einer Übertragung oder mit gleichbleibender Paketlaufzeit zu erhalten.

Bündelprotokolle sammeln Anwendungsdaten in Bündeln, die über verschiedene Netzwerke mit einer hohen [[Class of Service|Servicepriorität]] übermittelt werden können. Die Servicepriorität wird generell durch die Anwendung vorgegeben, die <nowiki>RFC 5050</nowiki> ''Bundle Protocol Specification''<ref name="RFC5050" /> sieht dafür die Prioritätsstufen ''{{lang|en|bulk}}'', ''{{lang|en|normal}}'' und ''{{lang|en|expedited}}'' vor.

=== Sicherheit ===
Die sichere Adressierung ist einer der Kernpunkte des Bündelprotokolls.

Die Sicherheitsansprüche für ein DTN-Netzwerk unterscheiden sich je nach Anwendung und Arbeitsumgebung, aber [[Authentifizierung]] und Vertraulichkeit spielen oft eine große Rolle. Ein bestimmtes Sicherheitsniveau in einem Netz ohne permanente Verbindungen zu garantieren ist schwierig, weil damit kryptographische Protokolle oder ein Schlüsselaustausch aufwendig wird, und die Notwendigkeit besteht, dass ein beliebiger Netzwerkknoten ständig andere nur temporär im Netz erreichbare Netzwerkknoten sicher erkennen muss.<ref>A. Kate, G. Zaverucha, U. Hengartner: ''Anonymity and security in delay tolerant networks''. 3rd International Conference on Security and Privacy in Communication Networks (SecureComm 2007).</ref><ref>S. Farrell, V. Cahill: ''Security Considerations in Space and Delay Tolerant Networks''. In: ''Proceedings of the 2nd IEEE International Conference on Space Mission Challenges for Information Technology''.</ref> Die implementierten Lösungen wurden oft aus den mobilen Ad-hoc-Netzwerktechniken abgeleitet und sind von Forschungen zur Datensicherheit beeinflusst worden, wie etwa der Nutzung von verteilten Zertifizierungsstellen und [[Public-Key-Infrastruktur|PKI]]-Schemata. Aus dem DTN-Bereich selbst stammt die Anwendung der ID-basierten Kryptografie, die es Netzwerkknoten ermöglicht, mit ihrer öffentlichen ID verschlüsselte Daten zu empfangen.<ref>A. Seth, S. Keshav: ''Practical security for disconnected nodes''. 1st IEEE ICNP Workshop on Secure Network Protocols (NPSec), 2005.</ref>

== Forschungsansätze ==
Die sich aus den Anforderungen an das DTN ergebenden Probleme werden derzeit von verschiedenen Institutionen untersucht:

* [http://www.dtnrg.org/ The Delay Tolerant Networking Research Group].
* [http://tier.cs.berkeley.edu/ Technology and Infrastructure for Developing Regions] Projekt bei der [[University of California, Berkeley|UC Berkeley]]
* Das KioskNet-Forschungsprojekt an der [[University of Waterloo]].
* [http://www.casa.umass.edu/main/research/massachusetts_test_bed/ DOME] Forschungsprojekt an der [[University of Massachusetts]], Amherst.
* [http://wiki.ittc.ku.edu/resilinets ResiliNets Research Initiative] an der [[University of Kansas]] und der [[Lancaster University]].
* [http://haggleproject.org/ Haggle] Forschungsprojekt der Europäischen Union
* [http://www.n4c.eu/ N4C] Forschungsprojekt FP7 der Europäischen Union
* [https://www.caida.org/workshops/aims/1403/slides/aims1403_cpartridge_related.pdf WNaN] DARPA Projekt

Einige Forschungsprojekte zum DTN für ein [[Interplanetary Internet]] untersuchen bereits die Nutzung des Bundle Protocols im All:
* Das [http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ Saratoga] Projekt der [[University of Surrey]] testete 2008 als erstes das Bundle-Protokoll im All mit dem UK-DMC [[Disaster Monitoring Constellation]] Satelliten.<ref>L. Wood et al.: {{Webarchiv |url=http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/ |text=''Use of the Delay-Tolerant Networking Bundle Protocol from Space''. |wayback=20080513145740}}, Conference paper IAC-08-B2.3.10, 59th International Astronautical Congress, Glasgow, September 2008.</ref><ref>{{Webarchiv |url=http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254 |text=''UK-DMC satellite first to transfer sensor data from space using ‘bundle’ protocol''. |wayback=20120426220355}} Surrey Satellite Technology Ltd, press release, 11. September 2008</ref><ref>Robin Wolstenholme: {{Webarchiv |url=http://www.engineeringbritain.com/space/archives/190-CLEO-Orbital-Internet-earns-Time-Magazine-award.html |text=''CLEO Orbital Internet earns Time Magazine award''. |wayback=20081207033626}} Surrey Satellite Technology Ltd space blog, 14. November 2008.</ref>
* [[NASA]] [[Jet Propulsion Laboratory|JPL]]'s Deep Impact Networking (DINET) Experiment an Bord der Raumfahrtsonde [[Deep Impact (Sonde)|Deep Impact]] / [[EPOXI]].<ref>{{Internetquelle |autor=Brittany Sauser |url=https://www.technologyreview.com/2008/10/27/217901/a-better-network-for-outer-space/ |titel=A Better Network for Outer Space |werk=MIT Technology Review |datum=2008-10-27 |sprache=en |abruf=2023-11-16}}</ref><ref>{{Internetquelle |url=https://www.govtech.com/dc/articles/nasa-successfully-tests-first-deep-space.html |titel=NASA Successfully Tests First Deep Space Internet |werk=government technology |datum=2010-07-27 |sprache=en |abruf=2023-12-11}}</ref>

== Weblinks ==
{{Commonscat|Delay-tolerant networking|Delay-Tolerant Networking}}

== Einzelnachweise ==
<references>
<ref name="RFC5050">
{{RFC-Internet |RFC=5050 |Titel=Bundle Protocol Specification |Datum=}}
</ref>
</references>

[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Netzwerkarchitektur]]
[[Kategorie:Wikipedia:Artikel mit Video]]

Delay-tolerant Networking - Versionsgeschichte

imported>Trustable: Trustable verschob die Seite Delay-Tolerant Networking nach Delay-tolerant Networking: Analog zu Any-source Multicast