SIS-DTN WG Meeting Thursday Afternoon 20090423

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 RFC5050. 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 http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt 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.

Requirements

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.

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)

RFC5050

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)

Primary Bundle Block

Bundle Status Control Flags 2 1 0 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Status Report| RESERVED|COS| General | 0 -- Bundle is a fragment. 1 -- Application data unit is an administrative record. 2 -- Bundle must not be fragmented. 3 -- Custody transfer is requested. 4 -- Destination endpoint is a singleton. 5 -- Acknowledgement by application is requested. 6 -- 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. 9 -13 -- reserved for future use. 14 -- Request reporting of bundle reception. 15 -- Request reporting of custody acceptance. 16 -- Request reporting of bundle forwarding. 17 -- Request reporting of bundle delivery. 18 -- 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

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

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.

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.

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)

Extension Blocks +-----------+-----------+-----------+-----------+ |Block type | Block processing ctrl flags (SDNV)| | Block length (SDNV) | / Block body data (variable) / 0 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+ | 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.

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

LTP

Identified Additional Capabilities

Takahiro’s Slides from Berlin