1

Comments on Delay Tolerant Network (DTN)

October, 2008Berlin, Germany

Takahiro Yamada, JAXA/ISAS

2

Purpose of This Presentation

I reviewed the following specifications (finally!). RFC 4838: Delay-Tolerant Networking Architecture RFC 5050: Bundle Protocol Specification draft-irtf-dtnrg-ltp-motivation-07: Licklider Transmission Proto

col - Motivation draft-irtf-dtnrg-ltp-10: Licklider Transmission Protocol - Specifi

cation This presentation describes some comments on these specificat

ions derived from our experience in developing both onboard and ground data systems form many science missions (including deep space missions) at JAXA/ISAS.

3

Class of Service (Priority) 1/3 The Bundle Protocol has four priority levels indicated by bits 7 an

d 8 in the Bundle Processing Control Flags (4.2 of RFC 5050). However, there are many deep space missions that use many (fo

r example, 100-200) priority levels for controlling the order of transmission from an onboard data storage (which may be a custodian) to the earth (or to the next node). These priority levels are usually indicated by or associated with APIDs and/or some other field in the packet secondary header.

Furthermore, on some missions, the priority level for some types of data changes depending on the occasion (for example, we give a high priority to thruster data after a maneuver).

We would appreciate it if the Bundle Protocol had a finer and more flexible mechanism for handling and controlling the priority of bundles.

4

Class of Service (Priority) 2/3

A possible solution is to use a Flow Label used in CFDP to control the order of transmission from nodes (which include custodians). A Flow Label is associated with each bundle and the assignment of its value is determined by the node that generates the bundle. Therefore, the meaning of the Flow Label values is determined by the source endpoint ID or by a group of endpoint IDs that share a method for controlling Flow Label values.

How Flow Label values should be mapped to the orders of transmission should be informed by some node using a bundle management protocol.

A similar thing can be done by using the source endpoint ID to determine the order of transmission (that is, source endpoint IDs map to priority levels), but I’m not sure this is practical.

5

Class of Service (Priority) 3/3

Furthermore, we sometimes want to give a high priority to bundles generated during a certain time period (for example, during a maneuver).

Therefore, having a standard creation timestamp in the bundle header (4.5.1 of RFC 5050) is a good idea.

We would be happier if there were a mechanism to inform a node (which may be a custodian) what bundles should be transferred first based on the value of the creation timestamp of the bundles stored at that node (using a bundle management protocol).

6

Bundle Sequence Number

We sometimes want to know whether or not there are missing bundles generated by a node (source endpoint).

For this purpose, we would appreciate having a bundle sequence number in the bundle header.

7

Bundle Management Protocol

It would be convenient for some missions if there were a protocol for managing bundles stored at a node (which may be a custodian).

This Bundle Management Protocol would do the following: Instruct a node to send a report to another node what bundle

s it has in its storage. Inform a node how Flow Label values should be mapped to th

e orders of transmission from that node. Inform a node what bundles should be transmitted first from

that node based on the value of the creation timestamp.

8

Linkage between BP and LTP

Let’s suppose that a bundle is sent from a node to another node using LTP. For some reason, the LTP engine at the sending node sends the bundle in five LTP segments.

Let’s suppose that the first three segments arrived at the receiving node (and were acknowledged by the receiver), but the last two segments did not. The session ends at this condition.

It would be nice if the receiving bundle agent could create a fragment of the original bundle from the three segments that were received correctly, and the sending bundle agent could create another fragment from the two remaining segments and retransmit it to the receiving node during the next session or to another node during a different session.

Is this mechanism too complex?