RFC 4838

Delay-Tolerant Networking Architecture

📅 published April 2007, from ietf

Delay-Tolerant Networking Architecture 🌸

okay bestie, this is RFC 4838, and it's literally the architecture doc for Delay-Tolerant Networking (DTN) 🛰️✨ It's an Informational RFC from April 2007, so it's not a standard, just a super smart description of an idea. It's from the Network Working Group, and the author list is stacked: V. Cerf (Google/Jet Propulsion Laboratory), S. Burleigh, A. Hooke, and L. Torgerson (NASA/Jet Propulsion Laboratory), R. Durst and K. Scott (The MITRE Corporation), K. Fall (Intel Corporation), and H. Weiss (SPARTA, Inc.) 💅 The header doesn't list anything it obsoletes or updates.

Status of This Memo 📜

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶

Copyright (C) The IETF Trust (2007).

IESG Note 🧠

This RFC is a product of the Internet Research Task Force (IRTF), so it's not a candidate for any level of Internet Standard. The IRTF shares results of Internet-related research and development. Those results might not be suitable for deployment on the public Internet, so calm down before you ship anything 💀

Abstract 🔭

okay so this doc describes an architecture for delay-tolerant and disruption-tolerant networks. It's an evolution of the architecture first designed for the Interplanetary Internet, which was meant to give Internet-like services across interplanetary distances to support deep space exploration 🚀 🪐

The main problem is internetworks where the operational and performance conditions make normal Internet-style networking either unworkable or impractical. The fix is a message-oriented overlay that sits above the transport (or other) layers of the networks it connects 🦋 The doc covers the motivation, an architectural overview, the state management the design needs to run, and application design issues. It represents the consensus of the IRTF DTN research group, and that group reviewed it extensively 🎀

Table of Contents 🗂️

1. Introduction ....................................................3
2. Why an Architecture for Delay-Tolerant Networking? ..............4
3. DTN Architectural Description ...................................5
   3.1. Virtual Message Switching Using Store-and-Forward
        Operation ..................................................5
   3.2. Nodes and Endpoints ........................................7
   3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
   3.4. Anycast and Multicast .....................................10
   3.5. Priority Classes ..........................................10
   3.6. Postal-Style Delivery Options and Administrative Records ..11
   3.7. Primary Bundle Fields .....................................15
   3.8. Routing and Forwarding ....................................16
   3.9. Fragmentation and Reassembly ..............................18
   3.10. Reliability and Custody Transfer .........................19
   3.11. DTN Support for Proxies and Application Layer Gateways ...21
   3.12. Timestamps and Time Synchronization ......................22
   3.13. Congestion and Flow Control at the Bundle Layer ..........22
   3.14. Security .................................................23
4. State Management Considerations ................................25
   4.1. Application Registration State ............................25
   4.2. Custody Transfer State ....................................26
   4.3. Bundle Routing and Forwarding State .......................26
   4.4. Security-Related State ....................................27
   4.5. Policy and Configuration State ............................27
5. Application Structuring Issues .................................28
6. Convergence Layer Considerations for Use of Underlying
   Protocols ......................................................28
7. Summary ........................................................29
8. Security Considerations ........................................29
9. IANA Considerations ............................................30
10. Normative References ..........................................30
11. Informative References ........................................30
12. Acknowledgments ...............................................32

1. Introduction ✨

This doc describes an architecture for delay and disruption-tolerant interoperable networking (DTN) 💖 It embraces the ideas of networks that are only occasionally connected. Those networks can get split apart a lot, and they might be made of more than one different set of protocols or protocol families 🌈

The base for all of this is the Interplanetary Internet, which mainly focused on deep space communication in high-delay environments. The architecture is expected to be used in lots of operational environments, including ones with disruption and disconnection and ones with high delay. Deep space is one specialized example, and it's being pursued as a specialization of this architecture. (See [IPN01] and [SB03] for more details.) 🪐

Other networks this architecture applies to include sensor networks with scheduled intermittent connectivity, terrestrial wireless networks that usually can't keep end-to-end connectivity, satellite networks with moderate delays and periodic connectivity, and underwater acoustic networks with moderate delays and frequent interruptions from environmental factors 🌊🐋 If you're new, there's a DTN tutorial [FW03] that introduces DTN, the kinds of networks it's built for, and the fundamental concepts and motivation. For more technical reads, check [KF03], [JFP04], [JDPF05], and [WJMF05] 📚

Here's the core concept: the doc defines an end-to-end message-oriented overlay called the "bundle layer". It sits above the transport (or other) layers of the networks it runs on and below applications 🧚 Devices that implement the bundle layer are called DTN nodes. The bundle layer forms an overlay that uses persistent storage to fight network interruptions. It includes a hop-by-hop transfer of reliable delivery responsibility and optional end-to-end acknowledgement 💜 It also has a bunch of diagnostic and management features.

For interoperability, the bundle layer uses a flexible naming scheme based on Uniform Resource Identifiers [RFC3986]. That scheme can wrap different naming and addressing schemes in one overall naming syntax 🎀 It also has a basic security model that you can optionally turn on, aimed at protecting infrastructure from unauthorized use 🔒

The bundle layer does a similar job to the internet layer of gateways from the original ARPANET/Internet designs [CK74]. The difference is that it's layer-agnostic and focused on virtual message forwarding rather than packet switching 💅 Both still do the same big thing, which is providing interoperability between the protocols specific to one environment and those specific to another. Both also offer a store-and-forward service, except the bundle layer uses persistent storage for its store-and-forward function 🫶

Put simply, the DTN architecture is a common way to connect heterogeneous gateways or proxies that use store-and-forward message routing to get past communication disruptions. It's kind of like electronic mail, but with better naming, routing, and security 💌 Nodes that can't support the full set of capabilities this architecture needs can be supported by application-layer proxies acting as DTN applications 🦋

2. Why an Architecture for Delay-Tolerant Networking? 🤔

Okay so the motivation for this architecture comes from a few factors. I'm summarizing them below, but way more detail is in [SB03], [KF03], and [DFS02] 📖

The existing Internet protocols don't work well in some environments, because the Internet architecture bakes in some fundamental assumptions 💀

  • that an end-to-end path between source and destination exists for the duration of a communication session
  • (for reliable communication) that retransmissions based on timely and stable feedback from data receivers is an effective means for repairing errors
  • that end-to-end loss is relatively small
  • that all routers and end stations support the TCP/IP protocols
  • that applications need not worry about communication performance
  • that endpoint-based security mechanisms are sufficient for meeting most security concerns
  • that packet switching is the most appropriate abstraction for interoperability and performance
  • that selecting a single route between sender and receiver is sufficient for achieving acceptable communication performance

The DTN architecture is designed to relax most of these assumptions 🔥 It's based on a few design principles, summarized here (and talked about more in [KF03]):

  • Use variable-length (possibly long) messages (not streams or limited-sized packets) as the communication abstraction, to help the network make good scheduling and path selection decisions when possible.
  • Use a naming syntax that supports a wide range of naming and addressing conventions, to improve interoperability.
  • Use storage within the network to support store-and-forward operation over multiple paths and over potentially long timescales (that is, to support environments where many and/or no end-to-end paths may ever exist). Do not require end-to-end reliability.
  • Provide security mechanisms that protect the infrastructure from unauthorized use by discarding traffic as quickly as possible.
  • Provide coarse-grained classes of service, delivery options, and a way to express the useful lifetime of data, so the network can deliver data better for what applications need.

The bundle layer is guided by its own design principles, and also by a few application design principles 👑

  • Applications should minimize the number of round-trip exchanges.
  • Applications should cope with restarts after failure while network transactions remain pending.
  • Applications should inform the network of the useful life and relative importance of data to be delivered.

These issues get more detail in Section 5 🌟

3. DTN Architectural Description 🧚‍♀️

The previous section summarized the design principles that guide the definition of the DTN architecture. This section describes the major features of the architecture that come out of design decisions made with those principles in mind ✨ This is where the fun architecture stuff starts, bestie 💖

3.1. Virtual Message Switching Using Store-and-Forward Operation ✨

okay so a DTN-enabled app can send messages of basically any length 📦. These are called Application Data Units, or ADUs [CT90], and they're still subject to whatever limits the implementation has. The order of ADUs might not be preserved, so don't count on them arriving in the order you sent them 🙈. Apps normally send and receive ADUs as complete units, but a system interface that works differently isn't ruled out 🎀.

The bundle layer turns each ADU into one or more protocol data units called "bundles", and DTN nodes are the ones that forward them 🦋. A bundle has a defined format with two or more "blocks" in it. Each block holds either application data or other info needed to get the bundle to its destination(s). Blocks basically do the job of headers and payloads in other protocol architectures 💅. They're called "blocks" instead of "headers" because they might not sit at the very start of a bundle, which can happen when some processing needs it that way (like digital signatures) 🧚.

Bundles can get split up ("fragmented") into smaller constituent bundles (also called "fragments" or "bundle fragments") while they're in transit 🧩. Fragments are bundles too, so they can be fragmented again. Two or more fragments can be put back together anywhere in the network to form a new bundle ✨.

Bundle sources and destinations are named by Endpoint Identifiers (EIDs, more on these below) that can be different lengths. The source EID tells you who originally sent the bundle, and the destination EID(s) tell you who the final stop is 💖. Bundles also carry a "report-to" EID, which is used when someone asks for diagnostic output to go to an arbitrary entity, not necessarily the source 👀. An EID can point at one or more DTN nodes, so it works for multicast destinations or "report-to" destinations too 🌈.

Now the big vibe shift 😭. IP networks run on "store-and-forward" operation, but the assumption there is that the "storing" only lasts a modest amount of time, roughly on the order of queuing and transmission delay ⏱️. DTN is different. It doesn't assume network links are always up or reliable. Instead, it expects that nodes might choose to store bundles for some time 📚. We expect most DTN nodes to use some kind of persistent storage for this (disk, flash memory, etc.), and stored bundles to survive system restarts 💜.

Bundles carry an originating timestamp, a useful life indicator, a class of service designator, and a length 📏. This info gives bundle-layer routing a head start on knowing how big a requested data transfer is and what performance it needs 🔥. When a lot of queuing can happen in the network (which is the whole point of the DTN version of store-and-forward), knowing this stuff can be a huge help for scheduling and path selection decisions [JFP04] 🧠. The alternative, a stream-based abstraction built on packets, would make that scheduling way harder 😤. Packets do give some of the same benefits as bundles, but bigger aggregates let the network apply scheduling and buffer management to chunks of data that actually make more sense to applications 💅.

Here's the core of bundle-based forwarding: bundles get to wait in a queue until a communication opportunity ("contact") shows up 🚪. That brings with it these assumptions:

  1. that storage is available and well-distributed throughout the network,
  2. that storage is sufficiently persistent and robust to store bundles until forwarding can occur, and
  3. (implicitly) that this "store-and-forward" model is a better choice than attempting to effect continuous connectivity or other alternatives.

If a network is going to really support the DTN architecture, these assumptions need to be considered and need to be found to hold ✅. Even then, making long-term storage a fundamental part of DTN brings new problems 😬, especially around congestion management and denial-of-service mitigation. Node storage is basically a brand-new resource that has to be managed and protected 🛡️. A lot of DTN research is all about exploring these issues 🔬. Congestion is covered in Section 3.13, and security mechanisms (including ways for DTN nodes to protect themselves from handling unauthorized traffic from other nodes) are covered in [DTNSEC] and [DTNSOV] 🔐.

3.2. Nodes and Endpoints 🫶

A DTN node (or just "node" in this document) is an engine that sends and receives bundles. Put simply, it's an implementation of the bundle layer ⚙️. Applications use DTN nodes to send or receive ADUs carried in bundles. Apps also use DTN nodes when they're acting as report-to destinations for diagnostic info carried in bundles 📨. Nodes can be members of groups called "DTN endpoints", so a DTN endpoint is just a set of DTN nodes 🍓. A bundle counts as successfully delivered to a DTN endpoint once some minimum subset of the nodes in that endpoint has received it without error 🎉. That subset is called the "minimum reception group" (MRG) of the endpoint 💫. The MRG of an endpoint might point at one node (unicast), one node out of a group (anycast), or all the nodes in a group (multicast and broadcast) 🌸. And one node can be in the MRG of more than one endpoint 👑.

3.3. Endpoint Identifiers (EIDs) and Registrations 🪪

An Endpoint Identifier (EID) is a name that identifies a DTN endpoint. It's written using the general syntax of URIs (more on that below) 📝. With an EID, a node can figure out the MRG of the DTN endpoint that the EID names 🔍. Every node also has to have at least one EID that uniquely identifies it 💜.

Apps send ADUs to an EID, and they can also set things up so that ADUs sent to a particular EID get delivered to them 📬. Depending on how the EID is built (see below), some part of an EID might be wildcarded, which tends to be handy for diagnostic and routing purposes 🃏.

When an app wants to receive ADUs sent to a particular EID, that's called a "registration". Registrations are usually kept persistently by a DTN node 🗄️. That way, registration info survives app and operating system restarts 🔁.

Trying to set up a registration isn't guaranteed to work 😅. For example, an app could ask to register for ADUs using an Endpoint ID that the DTN node handling the request can't interpret or doesn't have available 🙃. Requests like that are likely to fail 💀.

3.3.1. URI Schemes 🌐

Each Endpoint ID is written as a Uniform Resource Identifier (URI) [RFC3986]. URI syntax was designed to express names or addresses for a huge range of purposes, which makes it a great fit for building names for DTN endpoints 🦋.

In URI terminology, every URI starts with a scheme name. The scheme name has to be one of the globally-managed scheme names that IANA maintains [ISCHEMES]. Right after the scheme name comes a series of characters governed by the syntax that the scheme defines. This part of the URI is called the scheme-specific part (SSP), and it can be pretty general 🧩. (For one example, look at the URI scheme for SNMP [RFC4088].) Keep in mind that scheme-specific syntax and semantic restrictions can be stricter than the basic rules of RFC 3986 🤓. Section 3.1 of RFC 3986 has the guidance on the syntax of scheme names.

URI schemes are a key concept in the DTN architecture. They evolved from an earlier concept called regions, which were tied much more closely to assumptions about network topology 🗺️. Using URIs gives a lot of flexibility in how EIDs are structured 🎨. For example, they might be built from DNS names, or they might look like "expressions of interest" or database-like queries, like in a directed diffusion-routed network [IGE00] or in intentional naming [WSBL99] 💭. As names, EIDs don't have to be related to routing or topological organization 🙌. That relationship isn't prohibited, though, and in some environments using EIDs that way could be a real advantage ✨.

A single EID can refer to an endpoint with more than one DTN node, as hinted above 👯. It's up to the scheme designer to define how the SSP of an EID gets interpreted, so that it's clear whether the EID refers to a unicast, multicast, or anycast set of nodes. See Section 3.4 for more details 📖.

URIs are built using the rules in RFC 3986 and the US-ASCII character set 🔤. But here's a note from RFC 3986, Section 1.2.1, about dealing with characters that US-ASCII can't represent:

"Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US- ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI".

3.3.2. Late Binding ⏳

Binding means interpreting the SSP of an EID so that an associated message can be carried toward a destination 🧭. For example, binding might mean mapping an EID to a next-hop EID or to a lower-layer address for transmission 🗝️. "Late binding" means that tying a bundle's destination to a particular set of destination identifiers or addresses doesn't necessarily happen at the bundle source 🕰️. Since the destination EID can be re-interpreted at each hop, the binding might happen at the source, during transit, or possibly at the destination(s) 🔀. This is different from the name-to-address binding in Internet communications, where a DNS lookup at the source fixes the IP address of the destination node before any data is sent 📡. That would count as "early binding", because the name-to-address translation happens before data goes into the network 🚫.

In a network that's frequently disconnected, late binding can be a real win 🌙. The transit time of a message might be longer than how long a binding stays valid, which would make binding at the source impossible or invalid ⌛. Also, name-based routing with late binding may cut down on how much administrative (mapping) info has to spread through the network 🌊. It can also keep mapping synchronization limited to the local topological neighborhood where the changes happen 🏘️.

3.4. Anycast and Multicast ✨

Okay so, an EID can point at an endpoint made up of one or more DTN nodes, as we mentioned above 🧚. When that group has more than one member, the delivery semantics may be either anycast or multicast (broadcast counts as multicast 📡). With anycast, a bundle is delivered to one node out of a group of potentially many. With multicast, it's meant to reach all of them, subject to the normal DTN class of service and maximum useful lifetime semantics 💅.

Group membership in a DTN is a whole new vibe 🙈. In relatively low-delay networks like the Internet, nodes count as group members if they've joined "recently." In a DTN, though, nodes may want data that was sent to a group earlier than the moment they can actually receive it [ZAZ05] 😭. Here's the precise version: an application says it wants data sent to EID e at time t. Before that, during the interval [t0, t1], where t > t1, data may have already been generated for group e. For the app to get any of that data, the data has to stay available a potentially long time after senders have stopped sending to the group. So the data may need to be stored inside the network to support temporal group semantics like this 🌈. How to design and implement this is still a research issue, and it's likely at least as hard as the problems around reliable multicast 🥲.

3.5. Priority Classes 💜

The DTN architecture offers relative measures of priority (low, medium, high) for delivering ADUs 🎀. These priorities let an application affect how urgently its ADUs get delivered, and they're carried in bundle blocks that the bundle layer generates based on what the application specified 🔥.

The (U.S. or similar) Postal Service is a perfect metaphor for the priority classes in the DTN forwarding abstraction 📮. Traffic is usually not interactive and is often one-way. There are no strong guarantees of timely delivery, but there are some forms of class of service, reliability, and security 🫶.

We've defined three relative priority classes so far. They typically imply some relative scheduling prioritization among the bundles queued at a sender:

  • Bulk - Bulk bundles are shipped on a "least effort" basis. No bundles of this class will be shipped until all bundles of other classes bound for the same destination and originating from the same source have been shipped. 🐢
  • Normal - Normal-class bundles are shipped prior to any bulk-class bundles and are otherwise the same as bulk bundles. 🌸
  • Expedited - Expedited bundles, in general, are shipped prior to bundles of other classes and are otherwise the same. 🚀

Applications specify their requested priority class and data lifetime (see below) for each ADU they send. That info, combined with the policy applied at DTN nodes that choose how messages get forwarded and which routing algorithms are in use, affects the overall likelihood and timeliness of ADU delivery 🍓.

The priority class of a bundle only has to relate to other bundles from the same source 💖. So a high-priority bundle from one source may not get delivered faster (or with any other superior quality of service) than a medium-priority bundle from a different source. What it does mean is that a high-priority bundle from one source gets handled preferentially over a lower-priority bundle sent from that same source 👑.

Depending on a particular DTN node's forwarding and scheduling policy, priority may or may not be enforced across different sources. For example, some DTN nodes might always send expedited bundles before any bulk bundles, no matter where they came from. Many variations are possible 🦋.

3.6. Postal-Style Delivery Options and Administrative Records 📬

Continuing the postal analogy 💅, the DTN architecture supports several delivery options that an application can select when it requests transmission of an ADU. The architecture also defines two types of administrative records: "status reports" and "signals" 🧾. These records are bundles that carry information about the delivery of other bundles, and they're used together with the delivery options ✨.

3.6.1. Delivery Options 🎀

We've defined eight delivery options 🤩. An application sending an ADU (the "subject ADU") may request any combination of the following. They're carried in each of the bundles produced ("sent bundles") by the bundle layer as a result of the application's request to send the subject ADU:

  • Custody Transfer Requested - requests that sent bundles be delivered with enhanced reliability using custody transfer procedures. Sent bundles will be transmitted by the bundle layer using reliable transfer protocols (if available), and the responsibility for reliable delivery of the bundle to its destination(s) may move among one or more "custodians" in the network. This capability is described in more detail in Section 3.10. 🤝
  • Source Node Custody Acceptance Required - requires the source DTN node to provide custody transfer for the sent bundles. If custody transfer isn't available at the source when this delivery option is requested, the requested transmission fails. This gives applications a way to insist that the source DTN node take custody of the sent bundles (e.g., by storing them in persistent storage) 🔒.
  • Report When Bundle Delivered - requests a (single) Bundle Delivery Status Report be generated when the subject ADU is delivered to its intended recipient(s). This request is also known as "return-receipt" 📨.
  • Report When Bundle Acknowledged by Application - requests an Acknowledgement Status Report be generated when the subject ADU is acknowledged by a receiving application. This only happens by action of the receiving application, and it differs from the Bundle Delivery Status Report. It's meant for cases where the application may be acting as a form of application layer gateway and wants to indicate the status of a protocol operation external to DTN back to the requesting source. See Section 11 for more details 🌉.
  • Report When Bundle Received - requests a Bundle Reception Status Report be generated when each sent bundle arrives at a DTN node. This is designed primarily for diagnostic purposes 🔍.
  • Report When Bundle Custody Accepted - requests a Custody Acceptance Status Report be generated when each sent bundle has been accepted using custody transfer. This is designed primarily for diagnostic purposes 🩺.
  • Report When Bundle Forwarded - requests a Bundle Forwarding Status Report be generated when each sent bundle departs a DTN node after forwarding. This is designed primarily for diagnostic purposes 🛫.
  • Report When Bundle Deleted - requests a Bundle Deletion Status Report be generated when each sent bundle is deleted at a DTN node. This is designed primarily for diagnostic purposes 🗑️.

The first four delivery options are designed for ordinary use by applications 💖. The last four are designed primarily for diagnostics, and their use may be restricted or limited in environments that are subject to congestion or attack 🚨.

If the security procedures defined in [DTNSEC] are also enabled, then three additional delivery options become available 🛡️:

  • Confidentiality Required - requires the subject ADU be made secret from parties other than the source and the members of the destination EID 🤫.
  • Authentication Required - requires all non-mutable fields in the bundle blocks of the sent bundles (i.e., those which don't change as the bundle is forwarded) be made strongly verifiable (i.e., cryptographically strong). This protects several fields, including the source and destination EIDs and the bundle's data. See Section 3.7 and [BSPEC] for more details 🔐.
  • Error Detection Required - requires modifications to the non-mutable fields of each sent bundle be made detectable with high probability at each destination 🕵️‍♀️.

3.6.2. Administrative Records: Bundle Status Reports and Custody Signals 📋

Administrative records are used to report status information or error conditions related to the bundle layer 🫧. There are two types defined: bundle status reports (BSRs) and custody signals. Administrative records correspond (approximately) to messages in the ICMP protocol in IP [RFC792]. The difference is that in ICMP, messages are returned to the source. In DTN, they're instead directed to the report-to EID for BSRs, and to the EID of the current custodian for custody signals, which might differ from the source's EID 🔄. Administrative records are sent as bundles with a source EID set to one of the EIDs associated with the DTN node generating the record. In some cases, the arrival of a single bundle or bundle fragment may trigger multiple administrative records (for example, when a bundle is replicated for multicast forwarding) 🪞.

The following BSRs are currently defined (also see [BSPEC] for more details) 💌:

  • Bundle Reception - sent when a bundle arrives at a DTN node. Generation of this message may be limited by local policy. 📥
  • Custody Acceptance - sent when a node has accepted custody of a bundle with the Custody Transfer Requested option set. Generation of this message may be limited by local policy. 🤲
  • Bundle Forwarded - sent when a bundle containing a Report When Bundle Forwarded option departs from a DTN node after having been forwarded. Generation of this message may be limited by local policy. 📤
  • Bundle Deletion - sent from a DTN node when a bundle containing a Report When Bundle Deleted option is discarded. This can happen for several reasons, such as expiration. Generation of this message may be limited by local policy, but it is required in cases where the deletion is performed by a bundle's current custodian ⏳.
  • Bundle Delivery - sent from a final recipient's (destination) node when a complete ADU, made up of sent bundles containing Report When Bundle Delivered options, is consumed by an application 🎉.
  • Acknowledged by application - sent from a final recipient's (destination) node when a complete ADU, made up of sent bundles containing Application Acknowledgment options, has been processed by an application. This generally involves specific action on the receiving application's part 🙌.

In addition to the status reports, the custody signal is currently defined to indicate the status of a custody transfer. These are sent to the current-custodian EID contained in an arriving bundle 🧷:

  • Custody Signal - indicates that custody has been successfully transferred. This signal appears as a Boolean indicator, and may therefore indicate either a successful or a failed custody transfer attempt. ✅❌

Administrative records must reference a received bundle 🔗. This is accomplished by a method for uniquely identifying bundles, based on a transmission timestamp and sequence number, which is discussed in Section 3.12 ⏰.

3.7. Primary Bundle Fields 🎀

Okay so bundles moving between DTN nodes follow a standard bundle protocol that's specified in [BSPEC] 💅 Here's a quick tour of most of the fields every bundle carries. The protocol has a mandatory primary block, an optional payload block (that's where the ADU data itself lives 📦), and a set of optional extension blocks. Blocks can be cascaded kinda like extension headers in IPv6, which is so clean 🧚 The following selected fields are all in the primary block, so every bundle and fragment has them:

  • Creation Timestamp - a combo of the bundle's creation time and a monotonically increasing sequence number, so the creation timestamp is guaranteed unique for each ADU coming from the same source 🔥 It's based on the time-of-day an application asked for an ADU to be sent, not when the bundle(s) actually hit the network. DTN nodes are assumed to have a basic time synchronization capability (see Section 3.12) ⏰
  • Lifespan - the time-of-day when the message stops being useful 💀 If a bundle is sitting in the network (including the source's DTN node) when its lifespan is reached, it may be discarded. The lifespan is expressed as an offset relative to the creation time.
  • Class of Service Flags - tells you the delivery options and priority class for the bundle ✨ Priority classes may be one of bulk, normal, or expedited. See Section 3.6.1 🫶
  • Source EID - the EID of the source (the first sender) 🌸
  • Destination EID - the EID of the destination (the final intended recipient(s)) 🦋
  • Report-To Endpoint ID - an EID saying where reports (return-receipt, route-tracing functions) should go. It may or may not be the same endpoint as the Source EID 👑
  • Custodian EID - the EID of the current custodian of a bundle (if there is one) 🍓

The payload block carries info about the payload (like its length) and the payload itself 💜 On top of the fields in the primary and payload blocks, each bundle can also have fields in additional blocks riding along with it. Check [BSPEC] for the extra details 🌈

3.8. Routing and Forwarding 🦋

Okay this section is my favorite, it's giving architecture realness 😭 The DTN architecture gives us a framework for routing and forwarding at the bundle layer for unicast, anycast, and multicast messages. Because DTN nodes might be connected using more than one kind of underlying network technology, the best way to describe a DTN network is abstractly, as a multigraph (a graph where vertices can be connected by more than one edge) 🕸️ Edges in this graph are generally time-varying when it comes to delay and capacity, and they're directional because one-way connectivity is totally possible. When an edge has zero capacity, it's considered to not be connected 🙈

Edges in a DTN graph can have serious delay, so it really matters where you measure time when you express an edge's capacity or delay ⏳ We go with expressing capacity and delay as functions of time, where time is measured at the point where data gets inserted into a network edge. Like, say an edge has capacity C(t) and delay D(t) at time t. If B bits go into this edge at time t, they all arrive by time t + D(t) + (1/C(t))*B. We assume C(t) and D(t) don't change significantly during the interval [t, t+D(t)+(1/C(t))*B] 💅

Edges can flip between positive and zero capacity, so you can describe an interval of time where the capacity is strictly positive, and where the delay and capacity can be treated as constant [AF03] ✨ This period is called a "contact" 🎀 The product of the capacity and the interval is a contact's "volume". If you know contacts and their volumes ahead of time, you can make intelligent routing and forwarding decisions (optimally for small networks) [JFP04] 🧠 Using a contact's volume to the max, though, means you need to be able to divide big ADUs and bundles into smaller routable units. DTN fragmentation handles that (see Section 3.9) 🧩

When delivery paths through a DTN graph are lossy, or contact intervals and volumes aren't known precisely ahead of time, routing computations get really hard 😵 How to handle that is an active area of work in the (emerging) research area of delay tolerant networking 🌱

3.8.1. Types of Contacts 🌈

Contacts usually land in one of several categories, mostly based on how predictable their performance is and whether someone has to do something to bring them into existence. So far, these are the major types of contacts that have been defined:

Persistent Contacts

Persistent contacts are always available, so no connection-initiation action is needed to set one up 💖 An 'always-on' Internet connection, like a DSL or Cable Modem connection, is a good example of this class.

On-Demand Contacts

On-Demand contacts need some action to get started, but then they work like persistent contacts until they're terminated 🔌 A dial-up connection is an example (at least from the dialer's point of view. From the dial-up service provider's view, it might count as an Opportunistic Contact, below 🤭).

Intermittent - Scheduled Contacts

A scheduled contact is an agreement to set up a contact at a particular time, for a particular duration 📅 An example is a link with a low-earth orbiting satellite. A node's list of contacts with the satellite can be built from the satellite's schedule of view times, capacities, and latencies 🛰️ Heads up though: for networks with big delays, the "particular time" depends on the delay. For example, a single scheduled contact between Earth and Mars wouldn't happen at the same instant in each location. It would be offset by the (non-negligible) propagation delay 🪐

Intermittent - Opportunistic Contacts

Opportunistic contacts aren't scheduled. They just pop up unexpectedly 🦋 Like, an unscheduled aircraft flying overhead and beaconing to advertise that it's available for communication would be an opportunistic contact ✈️ Another kind is an infrared or Bluetooth link between a personal digital assistant (PDA) and a kiosk in an airport concourse. The contact starts when the PDA is brought near the kiosk, and it lasts an undetermined amount of time (until the link is lost or terminated) 📱

Intermittent - Predicted Contacts

Predicted contacts aren't based on a fixed schedule. They're predictions of likely contact times and durations, based on a history of previously observed contacts or some other info 🔮 If you have enough confidence in a predicted contact, routes can be chosen based on it. This is an active research area, and a few approaches have been proposed [LFC05] 🧪

3.9. Fragmentation and Reassembly 🧩

DTN fragmentation and reassembly are designed to make bundle transfers more efficient 🚀 They do this by making sure contact volumes get fully used, and by avoiding retransmitting bundles that were already partly forwarded. There are two forms of DTN fragmentation/reassembly 👯

Proactive Fragmentation

A DTN node may split a block of application data into multiple smaller blocks and send each one as an independent bundle 🍰 In this case, the final destination(s) are the ones responsible for pulling the smaller blocks out of incoming bundles and reassembling them into the original larger bundle and, finally, the ADU 🫶 It's called proactive fragmentation because it's mostly used when contact volumes are known (or predicted) in advance 🔮

Reactive Fragmentation

DTN nodes sharing an edge in the DTN graph may fragment a bundle cooperatively when the bundle is only partly transferred 🤝 In this case, the receiving bundle layer changes the incoming bundle to mark it as a fragment, and then forwards it normally. The previous-hop sender may learn (via convergence-layer protocols, see Section 6) that only a portion of the bundle reached the next hop, and then send the remaining portion(s) when later contacts show up (possibly to different next-hops if routing changes) 🔄 It's called reactive fragmentation because the fragmenting happens after a transmission attempt has already taken place 🫠

Let's do an example, bestie 🛰️ Imagine a ground station G and two store-and-forward satellites, S1 and S2, in opposite low-earth orbit. While G is sending a large bundle to S1, a reliable transport layer protocol below the bundle layer (on each side) reports that the transmission ended, but that half the transfer finished successfully 😤 Now G can make a smaller bundle fragment with the second half of the original bundle and forward it to S2 when S2 is available 🌙 Meanwhile, S1 (now out of range of G) can build a new bundle from the first half of the original bundle and forward it to whatever next hop(s) it thinks are best 🚀

The reactive fragmentation capability doesn't have to be in every DTN implementation 🙅‍♀️ It needs a certain level of support from underlying protocols that might not be there, and it's pretty challenging when it comes to digital signatures and authentication codes on messages. When a signed message is only partly received, most message authentication codes will fail 💔 So when DTN security is present and enabled, it may be necessary to proactively fragment large bundles into smaller units that are easier to handle with digital signatures 🔐

Even if reactive fragmentation isn't in an implementation, the ability to reassemble fragments at a destination is still required in order to support DTN fragmentation 🚨 Also, for contacts whose volumes are small compared to typical bundle sizes, some incremental delivery approach must be used (e.g., checkpoint/restart) to prevent data delivery livelock 😱 Reactive fragmentation is one such approach, but other protocol layers could potentially handle this issue too 💅

3.10. Reliability and Custody Transfer 🎀

okay so the most basic thing the bundle layer does is unacknowledged, prioritized (but not guaranteed) unicast delivery 💅 that's the baseline. it also gives you two upgrades for reliability: end-to-end acknowledgments and custody transfer. apps that want their own end-to-end reliability can totally use the acknowledgment if they want 🫶 custody transfer is only a coarse-grained retransmission thing, which we'll get into next.

so when a bundle has the Custody Transfer Requested option, the job of making sure an ADU's bundles get delivered gets passed around between different DTN nodes 🦋 for unicast, that usually means moving bundles "closer" (by some routing metric) to their final destination(s) and resending when needed. the nodes along the way that agree to take on that reliable delivery responsibility are called "custodians" 👑 when a bundle gets handed from one node to another, that's called a "custody transfer," and it's basically like a database commit transaction [FHM03] ✨ the exact meaning and design of custody transfer for multicast and anycast is still being figured out, so no promises there 🙈

custody transfer lets the source hand off the retransmission duty and free up its retransmission resources pretty quickly after sending (like, around the minimum round-trip time to the first bundle hop(s)) 🌸 it's not a true hop-by-hop thing though, because the DTN architecture doesn't require every node to accept custody. some nodes might have enough storage to sometimes be custodians, but they can opt out when they're congested or low on power 🔋

custodians can also change how DTN routing works 🧚 sometimes it's smart to get a bundle to a custodian asap, even if that custodian is farther from the final destination(s) (in distance, time, or some routing metric) than some other reachable node. building that capability means constructing more than one routing graph, and that's still an area of ongoing research 🔬

ngl this next bit is the (weak) part: custody transfer gives you a way to track bundles that need special handling and to figure out which DTN nodes take part in custody transfer 📋 it also gives a bit of a boost to delivery reliability. mostly though, custody transfer leans on the reliable delivery protocols of the underlying networks to do the heavy lifting from one bundle node to the next (set) 💖 when custody transfer is requested, the bundle layer adds its own coarse-grained timeout and retransmission mechanism, plus a bundle-layer custodian-to-custodian acknowledgment signaling mechanism 🎀 if an application does not request custody transfer, that bundle-layer timeout and retransmission thing usually isn't used at all, and delivery just depends on the underlying protocols' reliability 🫠

when a node accepts custody for a bundle with the Custody Transfer Requested option, the bundle layer sends a Custody Transfer Accepted Signal to the Current Custodian EID in the primary bundle block 💌 and before the bundle gets forwarded, the Current Custodian EID gets updated to hold one of the forwarding node's (unicast) EIDs ✨

custody transfer requests are advisory, which means an app asking for ADU delivery with custody transfer is just making a request 🙃 sometimes the bundle's source can't actually provide that service. when that happens, the bundle might go through multiple DTN nodes before it finally gets a custodian. those bundles get marked specially, with their Current Custodian EID field set to a null endpoint 🧸 if an app really needs the source to take custody, it can use the Source Node Custody Acceptance Required delivery option 🔒 that can be useful for apps that want an unbroken "chain" of custody, or that want to bounce only after they know their data is safely held by a custodian 🦋

now the spicy part 🌶️😭 in a DTN network where one or more custodian-to-custodian hops are strictly one-directional (and can't be reversed), custody transfer gets messed up over those hops. there's no way to get a custody signal (or any other info) back across the path, so the bundle ends up expiring at the ingress to that one-way hop. that doesn't automatically mean the bundle is lost! nodes on the far side can keep transferring custody, and the bundle might still get delivered to its destination(s) 🌈 BUT, if the source asked to receive expiration BSRs for the bundle, it'll get an expiration report and might (incorrectly!) think the bundle was discarded and never delivered 💀 this can't be fully fixed in this situation, but there's a mechanism to help with the misleading info: the node at the ingress to the one-way hop reports that a known one-way path exists, using a variant of a bundle status report 🧚 those reports only show up if the bundle asked for them with the 'Report When Bundle Forwarded' delivery option ✨

3.11. DTN Support for Proxies and Application Layer Gateways 🌸

one of DTN's goals is giving a common way to connect application layer gateways and proxies 🌍 when existing Internet apps can handle delays, you can build local proxies that use what DTN already offers [S05, T02] 💜 making those proxies DTN-compatible takes a load off the proxy author, who doesn't have to worry about routing and reliability management themselves, and it means existing TCP/IP-based apps can run unmodified over a DTN-based network 🙌

when DTN gets used to tunnel other protocols, it can help build overlay networks made of application layer gateways 🕸️ the application acknowledgment capability was made for exactly this situation 🎯 it gives remote application layer gateways a common way to report whether non-DTN protocol operations, started because they received DTN ADUs, worked or failed ✅ without that, apps would have to build these signals themselves in non-standard ways 😩

3.12. Timestamps and Time Synchronization ⏰

the DTN architecture needs time synchronization among DTN nodes (supported by external, non-DTN protocols) for four main things: bundle and fragment identification, routing with scheduled or predicted contacts, bundle expiration time computations, and application registration expiration 🕰️✨

bundle identification and expiration work because every bundle carries a creation timestamp and an explicit expiration field (in seconds after the source timestamp) 💖 the origination timestamps on arriving bundles get handed to consuming apps in the ADUs they receive, through some system interface function 📬 each set of bundles for an ADU is required to have a timestamp unique to the sender's EID 🔑 the EID, timestamp, and data offset/length info together uniquely identify a bundle 🪪 that unique ID is used for lots of stuff, like custody transfer and reassembling bundle fragments 🧩

time also matters for application registrations 🎀 when an app says it wants ADUs destined for a particular EID, that registration only sticks around for a finite period, which the app can set itself 💅 for multicast registrations, an app can also set a time range (aka an "interest interval") for its registration 🦋 in that case, traffic sent to the specified EID at any point during that interval will eventually get delivered to the app 💫 (unless it has expired because of the expiration time the app set at the source, or something else gets in the way of delivery 🥲)

3.13. Congestion and Flow Control at the Bundle Layer ✨

okay so bestie, the authors of this document have not yet reached complete consensus on congestion and flow control at the bundle layer 😭 it's a whole debate! we still have unresolved worries about how well these schemes work over long and/or highly variable delay links, especially with custody transfer, which can make nodes hang onto bundles for really long stretches ⏳

for this doc, "flow control" means making sure the average rate a sending node pushes data at does not go over the average rate the receiving node is ready to take it from that sender 🌊 (and yes, this is a generalized idea, not just end-to-end stuff 💅). "Congestion control" is about making sure the total rate all the traffic sources pump into a network never goes above the maximum total rate the network can actually deliver to destination nodes over time 🚦. If flow control gets pushed backward from congested nodes toward the traffic sources, then flow control can be at least a partial fix for congestion too 🫶

DTN flow control decisions have to be made inside the bundle layer itself, based on info about resources available in the bundle node (mostly persistent storage 💾). when storage gets scarce, a DTN node doesn't have a ton of options 😬 It can always toss bundles that have expired (which nodes should do regularly anyway, bestie 🧹). If it normally accepts custody for bundles, it can stop doing that. If storage is available elsewhere in the network, it might be able to use it somehow for bundle storage. It can also discard bundles that haven't expired but that it hasn't accepted custody for. A node must avoid discarding bundles it has accepted custody for, and only do that as a last resort 🥺 Figuring out when a node should start or stop custody transfers is a resource allocation and scheduling problem that's super hot in current research 🔥

Also, a DTN node might be able to get help from lower-layer protocols to manage its own resource use 🧚. For example, a DTN node receiving a bundle over TCP/IP might on purpose slow its receiving rate by doing read operations less often, to cut its offered load. This works because TCP has its own flow control, so reducing how fast the application consumes data could effectively act as a form of hop-by-hop flow control. Unfortunately, it may also cause head-of-line blocking issues, depending on how bundles are multiplexed within a TCP connection 💀. A protocol with more relaxed ordering constraints (e.g. SCTP [RFC2960]) might be preferable in those situations 🌸

Congestion control is an ongoing research topic 🔬

3.14. Security 🔐

the possibility of severe resource scarcity in some delay-tolerant networks means that some form of authentication and access control to the network itself is required in many circumstances. It's not acceptable for an unauthorized user to flood the network with traffic easily, possibly denying service to authorized users 🚨. In lots of cases it's also not acceptable for unauthorized traffic to be forwarded over certain network links at all, and that's especially true for exotic, mission-critical links 🛰️. With all of that in mind, the security part of the DTN architecture has several goals:

  • Promptly prevent unauthorized applications from having their data carried through or stored in the DTN. 🚫
  • Prevent unauthorized applications from asserting control over the DTN infrastructure. 👑
  • Prevent otherwise authorized applications from sending bundles at a rate or class of service for which they lack permission. 🎟️
  • Promptly discard bundles that are damaged or improperly modified in transit. 🧽
  • Promptly detect and de-authorize compromised entities. 🕵️

Lots of existing authentication and access control protocols were designed for low-delay, connected environments, so they may not perform well in DTNs 😩. Updating access control lists and revoking ("blacklisting") credentials could be especially hard. Also, approaches that need frequent access to centralized servers to finish an authentication or authorization transaction aren't attractive. The consequences? Delays in starting communication, delays in detecting and recovering from system compromise, and delays in completing transactions because of inappropriate access control or authentication settings 🐢

To help meet these security requirements given the challenges, the DTN architecture adopts a standard but optionally deployed security architecture [DTNSEC] that uses hop-by-hop and end-to-end authentication and integrity mechanisms 🦋. The point of using both approaches is to handle access control for data forwarding and storage separately from application-layer data integrity. End-to-end provides authentication for a principal such as a user (of which there may be many), while hop-by-hop is meant to authenticate DTN nodes as legitimate transceivers of bundles to each other. It's conceivable to build a DTN where only a subset of nodes take part in the security mechanisms, resulting in a secure DTN overlay sitting on top of an insecure DTN overlay. This idea is relatively new and still being explored 🧠

In line with the goals above, DTN nodes discard traffic as early as possible if authentication or access control checks fail 🗑️. This meets the goal of keeping unwanted traffic off specific high-value links, and it also makes denial-of-service attacks considerably harder to mount more generally, compared with conventional Internet routers 🛡️. The obvious cost is potentially larger computation and credential storage overhead at DTN nodes 💸

For more detailed info on DTN security provisions, refer to [DTNSEC] and [DTNSOV] 📚

4. State Management Considerations 🗂️

An important aspect of any networking architecture is how it manages state ✨. This section describes the state managed at the bundle layer and talks about how it gets established and removed.

4.1. Application Registration State 📝

In long/variable delay environments, an asynchronous application interface seems most appropriate 🕰️. These interfaces typically include methods for applications to register callback actions when certain triggering events happen (e.g., when ADUs arrive). Those registrations create state info called application registration state.

Application registration state is typically created by an explicit request from the application, and removed by a separate explicit request, but it may also be removed by an application-specified timer (so it's "firm" state 💪). In most cases there must be a provision for keeping this state across application and operating system termination/restart conditions, because a client/server bundle round-trip time may exceed the requesting application's execution time (or the hosting system's uptime) 🔁. In cases where applications aren't automatically restarted but registration state stays persistent, a method must be provided to tell the system what action to perform when the triggering event occurs (e.g., restarting some application, ignoring the event, etc.) 🎯

To start a registration and establish application registration state, an application specifies an Endpoint ID it wants to receive ADUs for, along with an optional time value for how long the registration should stay active. This is kinda analogous to the bind() operation in the common sockets API 🔌

For registrations to groups (i.e., joins), a time interval may also be specified. The time interval refers to the range of origination times of ADUs sent to the specified EID. See Section 3.4 above for more details 📅

4.2. Custody Transfer State 📦

Custody transfer state is the info needed to keep account of bundles a node has taken custody of, plus the protocol state for transferring custody of one or more of them. The accounting-related state is created when a bundle is received. Custody transfer retransmission state is created when a transfer of custody is initiated by forwarding a bundle with the custody transfer requested delivery option specified. Retransmission state and accounting state may be released when one or more Custody Transfer Succeeded signals arrive, indicating custody has been moved ✅. Plus, the bundle's expiration time (possibly mitigated by local policy) gives an upper bound on when this state gets purged from the system if it isn't purged explicitly because a signal came in ⏰.

4.3. Bundle Routing and Forwarding State 🧩

Just like the Internet architecture, we split routing and forwarding. Routing is running a (possibly distributed) algorithm to compute routing paths according to some objective function (see [JFP04], for example). Forwarding is the act of moving a bundle from one DTN node to another 🚚. Routing uses routing state (the RIB, or routing information base), while forwarding uses state derived from routing, maintained as forwarding state (the FIB, or forwarding information base). The structure of the FIB and the rules for maintaining it are implementation choices 🛠️. In some DTNs, exchanging the info used to update RIB state may happen on network paths different from where application data gets exchanged 🛤️.

The maintenance of RIB state depends on the type of routing algorithm in use. A routing algorithm may consider requested class of service and the location of potential custodians (for custody transfer, see section 3.10), and this info tends to increase the size of the RIB 📈. The separation between FIB and RIB is not required by this document, since these are implementation details for system implementers to decide. The choice of routing algorithms is still under study 🧪.

Bundles may sit in node queues for a considerable amount of time ⏳. For unicast or anycast delivery, that time is likely the interval between when a bundle arrives at a node and when it can be forwarded to its next hop. For multicast delivery of bundles, this could be significantly longer, up to a bundle's expiration time. This happens when multicast delivery is used so that nodes joining a group can get info previously sent to the group. In such cases, some nodes may act as "archivers" that provide copies of bundles to new participants that were already delivered to other participants 📚

okay so the DTN security approach in [DTNSEC] (when it's used, bestie 🔐) needs state kept in every DTN node that uses it. Every one of those nodes is required to store its own private information, which means its own policy and authentication material, plus a block of information used to verify credentials 🫶. And in most cases nodes will cache some public information (and possibly the credentials) of their next-hop (bundle) neighbors 💜. Everything cached has an expiration time ⏰, so nodes are responsible for getting and distributing updates of public information and credentials before the old set expires. That's how you avoid a disruption in network service, and nobody wants that 😭

In addition to basic end-to-end and hop-by-hop authentication, access control may be used in a DTN through one or more mechanisms such as capabilities or access control lists (ACLs) 💅. ACLs would be another block of state sitting in any node that wants to enforce security policy 🔥. They're usually set up at node configuration time, but they can be updated dynamically by DTN bundles or by some out of band technique ✨. Capabilities or credentials can be revoked, which means you need a revocation list (a "black list", another form of state) to check for invalid authentication material that has already been handed out 🙈

Some DTNs may set up security boundaries enforced by selected nodes in the network, where end-to-end credentials may get checked on top of the hop-by-hop credentials 🛡️ (doing so may require routing to be adjusted so that all bundles making up each ADU pass through these points 🗺️). Public information used to verify end-to-end authentication will typically be cached at these points 💖

4.5. Policy and Configuration State 🎀

DTN nodes will contain some amount of configuration and policy information 📋. This kind of information may alter the behavior of bundle forwarding 🔀. Examples of policy state include the types of cryptographic algorithms and access control procedures to use if DTN security is employed 🔐, whether nodes may become custodians 🧚, what types of convergence layer (see Section 6) and routing protocols are in use 🌸, how bundles of differing priorities should be scheduled 📅, where and for how long bundles and other data is stored 🗄️, what status reports may be generated or at what rate 📊, etc. ✨

5. Application Structuring Issues 🌈

DTN bundle delivery is intended to operate in a delay-tolerant fashion over a broad range of network types 🌍. This does not mean there must be large delays in the network 🙅‍♀️. It means there may be very significant delays, including extended periods of disconnection between sender and intended recipient(s) 🫠. The DTN protocols are delay tolerant, so applications using them must also be delay tolerant in order to operate effectively in environments subject to significant delay or disruption 💪

The communication primitives provided by the DTN architecture are based on asynchronous, message-oriented communication, which is really different from conversational request/response communication 💬. In general, applications should try to include enough information in an ADU so that the network and receiver(s) can treat it as an independent unit of work 🍓. The goal is to minimize synchronous interchanges between applications separated by a network with long and possibly highly variable delays ⏳. A single file transfer request message, for example, might include authentication information, file location information, and the requested file operation. That's the "bundling" part, bestie, all packed together 🎁. Compare this to a classic FTP transfer, and the bundled model can complete in one round trip, whereas an FTP file "put" operation can take as many as eight round trips to get to the point where file data can flow [DFS02] 😭🔥

Delay-tolerant applications have to think about more than just the conversational side of long delay paths 🧠. For example, an application may terminate (voluntarily or not) between the time it sends a message and the time it expects a response 💀. If that possibility has been anticipated, the application can be "re-instantiated" with state information saved in persistent storage 💾. This is an implementation issue, but it's also an application design consideration 🧩

Some thoughtful delay-tolerant application design can result in applications that work reasonably well in low-delay environments, and that don't suffer extraordinarily in high or highly-variable delay environments 🦋 iconic behavior, honestly ✨

6. Convergence Layer Considerations for Use of Underlying Protocols 🧩

Implementation experience with the DTN architecture has revealed an important architectural construct and interface for DTN nodes [DBFJHP04] 👑. Not all underlying protocols in different protocol families provide the exact same functionality, so some additional adaptation or augmentation on a per-protocol or per-protocol-family basis may be required 🔧. This adaptation is handled by a set of convergence layers placed between the bundle layer and the underlying protocols 🌉. The convergence layers manage the protocol-specific details of interfacing with particular underlying protocols, and they present a consistent interface to the bundle layer 💅

The complexity of one convergence layer can vary a lot from another, depending on the type of underlying protocol it adapts 📈. For example, a TCP/IP convergence layer for use in the Internet might only have to add message boundaries to TCP streams 🌊. A convergence layer for a network where no reliable transport protocol exists might be way more complex (e.g., it might have to implement reliability, fragmentation, flow-control, etc.) if reliable delivery is going to be offered to the bundle layer 🫣

As convergence layers implement protocols above and beyond the basic bundle protocol specified in [BSPEC], they will be defined in their own documents 📄. That works kind of like how encapsulations for IP datagrams are specified on a per-underlying-protocol basis, such as in RFC 894 [RFC894] 🎀

7. Summary 🌸

The DTN architecture tackles a lot of the problems of heterogeneous networks that have to operate in environments with long delays and discontinuous end-to-end connectivity 🌍. It's based on asynchronous messaging and uses postal mail as a model of service classes and delivery semantics 📬. It supports many different forms of connectivity, including scheduled, predicted, and opportunistically connected delivery paths 🚀. It introduces a novel approach to end-to-end reliability across frequently partitioned and unreliable networks 🫶. It also proposes a model for securing the network infrastructure against unauthorized access 🔐

It is our belief that this architecture is applicable to many different types of challenged environments 🏆

8. Security Considerations 🔐

Security is an integral concern for the design of the Delay Tolerant Network Architecture, but its use is optional. 🚨 Sections 3.6.1, 3.14, and 4.4 of this document present some factors to consider for securing the DTN architecture, but separate documents [DTNSOV] and [DTNSEC] define the security architecture in much more detail. Go read those, bestie, they're the real deal 🔐💜

9. IANA Considerations 📚

This document specifies the architecture for Delay Tolerant Networking, which uses Internet-standard URIs for its Endpoint Identifiers 🔗. URIs intended for use with DTN should be compliant with the guidelines given in [RFC3986] ✨

10. Normative References 📖

[RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66, RFC
            3986, January 2005.

11. Informative References ✨

okay bestie, this is the reading list 📚 these are the sources the doc points to for background, so they're not requirements. the vibe is "if you wanna go deeper, start here" 🦋

  • [IPN01] InterPlaNetary Internet Project, Internet Society IPN Special Interest Group, http://www.ipnsig.org.
  • [SB03] S. Burleigh, et al., "Delay-Tolerant Networking - An Approach to Interplanetary Internet", IEEE Communications Magazine, July 2003.
  • [FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial v1.1", Wartham Associates, 2003. Available from http://www.dtnrg.org.
  • [KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", Proceedings SIGCOMM, Aug 2003.
  • [JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant Network", Proceedings SIGCOMM, Aug/Sep 2004.
  • [DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard Internet Suite for the Interplanetary Internet?", MITRE White Paper, 2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf.
  • [CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Trans. on Comm., COM-22(5), May 1974.
  • [IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks", Proceedings MobiCOM, Aug 2000.
  • [WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, "The Design and Implementation of an Intentional Naming System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.
  • [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings SIGCOMM, 1990.
  • [ISCHEMES] IANA, Uniform Resource Identifer (URI) Schemes, http://www.iana.org/assignments/uri-schemes.html.
  • [JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to Cope with Failures in a Delay Tolerant Network", Proceedings SIGCOMM, 2005.
  • [WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding Based Routing in Opportunistic Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
  • [ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
  • [LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 2005.
  • [AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows over Time with Piecewise Constant Capacity and Transit Times", Intel Research Technical Report IRB-TR-03-007, June 2003.
  • [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable Delivery in Delay Tolerant Networks", Intel Research Technical Report IRB-TR-03-030, July 2003.
  • [BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", Work in Progress, December 2006.
  • [DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security Protocol Specification", Work in Progress, October 2006.
  • [DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant Networking Security Overview", Work in Progress, October 2006.
  • [DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, "Implementing Delay Tolerant Networking", Intel Research Technical Report IRB-TR-04-020, Dec. 2004.
  • [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
  • [RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1 1984.
  • [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
  • [RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", RFC 4088, June 2005.
  • [S05] K. Scott, "Disruption Tolerant Networking Proxies for On-the-Move Tactical Networks", Proc. MILCOM 2005 (unclassified track), Oct. 2005.
  • [T02] W. Thies, et al., "Searching the World Wide Web in Low-Connectivity Communities", Proc. WWW Conference (Global Community track), May 2002.

12. Acknowledgments 🫶

huge thank-you energy to everyone who helped shape this doc 💜 John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman, Michael Welzl, and Craig Partridge all gave useful thoughts and criticisms to versions of this document. we're so grateful for their time and participation 🌸

the work was done in part under DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407 ✨

Authors' Addresses 🎀

these are the humans behind the doc, with their contact info exactly as listed 💅

Dr. Vinton G. Cerf
Google Corporation
Suite 384
13800 Coppermine Rd.
Herndon, VA 20171
Phone: +1 (703) 234-1823
Fax:   +1 (703) 848-0727
EMail: vint@google.com
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099
Phone: +1 (818) 393-3353
Fax:   +1 (818) 354-1075
EMail: Scott.Burleigh@jpl.nasa.gov
Robert C. Durst
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA 22102
Phone: +1 (703) 983-7535
Fax:   +1 (703) 983-7142
EMail: durst@mitre.org
Dr. Kevin Fall
Intel Research, Berkeley
2150 Shattuck Ave., #1300
Berkeley, CA 94704
Phone: +1 (510) 495-3014
Fax:   +1 (510) 495-3049
EMail: kfall@intel.com
Adrian J. Hooke
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 303-400
Pasadena, CA 91109-8099
Phone: +1 (818) 354-3063
Fax:   +1 (818) 393-3575
EMail: Adrian.Hooke@jpl.nasa.gov
Dr. Keith L. Scott
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA 22102
Phone: +1 (703) 983-6547
Fax:   +1 (703) 983-7142
EMail: kscott@mitre.org
Leigh Torgerson
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 238-412
Pasadena, CA 91109-8099
Phone: +1 (818) 393-0695
Fax:   +1 (818) 354-6825
EMail: ltorgerson@jpl.nasa.gov
Howard S. Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
Phone: +1 (410) 872-1515 x201
Fax:   +1 (410) 872-8079
EMail: howard.weiss@sparta.com

please send comments to dtn-interest@mailman.dtnrg.org 📬 the Delay Tolerant Networking Research Group (DTNRG) web site is at http://www.dtnrg.org 🌈

Copyright (C) The IETF Trust (2007).

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

this document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't say it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 💜

the IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from