1. SIS-DTN WG Meeting
Thursday Afternoon

2. Goals from Charter B. GOALS
DTN-WG is a Standards Track Working Group. The Working Group will determine whether or not “Delay-Tolerant Networking” as specified in RFC5050 is a feasible solution for a store-and-forward networking protocol for space environments where data relay is likely.
If RFC5050 is deemed suitable overall but lacking in certain specific capabilities needed by the space community, this working group may define extensions to RFC5050 to address these needs. If RFC5050 is not suitable, the WG will attempt to define an alternate protocol that meets the needs of the space community.
RFC5050 requires a reliable data delivery service between overlay routers. While CCSDS has reliable data link protocols in TC and AOS, neither is well-suited for use as a convergence layer by RFC It is likely that any Delay Tolerant Networking protocol proposed by this group will need reliability on a hop-by-hop basis. Thus this working group will also standardize a reliable hop-by-hop data delivery service that can be used by the Delay Tolerant Networking protocol specified by this WG. The Licklider Transport Protocol (LTP) as described in the work-in-progress was designed for exactly this purpose, and will be the initial focus of this part of the WG effort.
Per standard CCSDS procedure, development of this Recommended Practice will entail demonstration of mission operations in a prototypical DTN-based network environment.

3. Requirements

4. Requirements (From Green Book)
An OSI Layer-3 (Network Layer) Service to Applications
Ability to handle arbitrarily-sized application-layer PDUs
Application-layer PDU delivery in the presence of delays / disruptions, including:
Long delays
Temporary Network Partitioning
Half-duplex communication paths
Contacts that require fragmentation of the network-layer PDU
Data Accountability
Optional Reliability
Prioritized Data
Data Link Layer Agility
Discussion about ‘end-to-ended-ness’ where source DTN node maintains state about bundles that were sent and can proactively retransmit if a bundle gets stuck (with custody taken) at some node.
[End-to-end reliability fallback.]
VT is prototyping this capability within ION.
[DS – Could use CFDP class-2 as the ‘transport layer’ atop DTN to provide end-to-endedness.]
New requirement – ‘end-to-end’ reliability.

5. Requirements (From Green Book)
Compatibility with the terrestrial network technologies
Security, including:
Authenticated access to the network
Integrity and confidentiality services for user data
Whether or not the various security mechanisms are invoked MUST be controllable by policy.
Management – The space internetworking protocol SHOULD provide mechanisms for:
Network management (monitoring, …)
Resource sharing / policy / management
Route construction and maintenance (possibility of dynamic routing)

6. RFC5050

7. Bundles Built up out of Blocks
Primary Bundle Block
Address information (source, dest, …),
treatment flags, QoS marking, creation time, lifetime
Other Block (s)
Other capabilities, e.g. security, extended QoS markings, metadata describing the payload, at-most-one-of-this-kind
Payload Block
The application-layer payload
Other Block (s)

8. Primary Bundle Block

9. Bundle Status Control Flags
|Status Report| RESERVED|COS| General | 0 -- Bundle is a fragment Application data unit is an administrative record Bundle must not be fragmented Custody transfer is requested Destination endpoint is a singleton Acknowledgement by application is requested Reserved for future use. The bits in positions 8 and 7 constitute a two-bit priority field : 00 = bulk 01 = normal 10 = expedited 11 is reserved for future use reserved for future use Request reporting of bundle reception Request reporting of custody acceptance Request reporting of bundle forwarding Request reporting of bundle delivery Request reporting of bundle deletion.
Recommended practices book: when an application SHOULD set (or not set) the various flags.
Some short of shared understanding of whether intermediate routers will respond to these requests or not.
Can be used to track the progress of a bundle in the network
Signals can be generated but not forwarded (if no route exists) – pull accounting information only if there’s a network error

10. Primary Bundle Block: Address Information
Common strings stored in dictionary with offsets in header.
Report-to not necessarily the same as the source.
Current custodian marked in header

11. Primary Bundle Block: Creation Time and Time To Live
Timestamps and time-to-live allow bundles to be purged from the network when no longer needed.

12. Bundle Identification
Source EID
Creation Timestamp
Second granularity
Creation Timestamp Sequence Number
Monotone increasing within a second
[DS – need a service interface.]
JS – questions about what happens when a high-priority bundle comes in to a node with no resources available due to having taken custody of other (presumably lower-priority) bundles.

13. About Time
The combination of (sending EID, Creation Timestamp, and Creation Timestamp Sequence Number) uniquely identifies a bundle
Loose time synchronization among nodes is required to support the time-to-live notion
Loose, like, to within 10s of seconds, e.g.
Some notion of using a countdown time instead of (creation, lifetime)

14. Extension Blocks
|Block type | Block processing ctrl flags (SDNV)| | Block length (SDNV) | / Block body data (variable) / | Flags | Block Processing Control Flags Bit Layout 0 - Block must be replicated in every fragment. 1 - Transmit status report if block can't be processed. 2 - Delete bundle if block can't be processed. 3 - Last block. 4 - Discard block if it can't be processed. 5 - Block was forwarded without being processed. 6 - Block contains an EID-reference field.

15. Extension Block Examples
Security
Hop-by-hop to protect the infrastructure
Payload integrity / confidentiality
Metadata
Metadata about the payload (e.g. description)
Extended QoS
At-most-one queueing behavior
Bundle-in-bundle encapsulation (tunneling)
Previous-hop identification

16. LTP

17. Identified Additional Capabilities

18. Takahiro’s Slides from Berlin