Transcript DTN comments Oct08 Yamada

Comments on Delay Tolerant
Network (DTN)
October, 2008
Berlin, Germany
Takahiro Yamada, JAXA/ISAS
1
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
Protocol - Motivation
 draft-irtf-dtnrg-ltp-10: Licklider Transmission Protocol Specification
This presentation describes some comments on these
specifications derived from our experience in developing both
onboard and ground data systems form many science missions
(including deep space missions) at JAXA/ISAS.
2
Class of Service (Priority) 1/3




The Bundle Protocol has four priority levels indicated by bits 7
and 8 in the Bundle Processing Control Flags (4.2 of RFC 5050).
However, there are many deep space missions that use many
(for 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.
3
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.
4
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).
5
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.
6
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
bundles it has in its storage.
 Inform a node how Flow Label values should be mapped to
the 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.
7
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?
8