SIS-DTN WG Meeting

1. SIS-DTN WG Meeting October 16, 2008 Berlin, Germany

2. Revised Agenda • Review SIS-DTN charter and work plan • Review of Spring 2008 meeting and significant events • Work items out of Spring meeting • SISG / IOAG presentation • NASA DTN-for-2010 work • Green Book Review • Goals • Comments • Direction / next steps • Volunteers • Long Erasure Codes Presentation • RFC5050 Discussion • Review of RFC5050 bundle protocol capabilities • Required capabilities for space (from Green Book and morning discussions) • Documents to Produce • Green Book • DTN Protocol Specification • Interfacing DTN to CCSDS link layers (LTP) • Goals for next meeting cycle

3. SIS-DTN Charter • 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.

4. Results of Spring Meetings • Yes, WG is justified, move forward • Support for protocol development and testing from NASA / ESA • Don’t try to solve world hunger – assume standardized and interoperable lower layer protocols • Get the Green Book Done First • Keith to write first draft

5. Important Event: IOAG Space Internet Strategy Group (SISG) Report […] the international community should begin the planning and development activities that are necessary to transition future space mission operations to rely on a new end-to-end internetworked model of data communications, using mission support infrastructure that spans across space. […] The CCSDS should be tasked to create a Space Internetworking Architecture document (in the form of a CCSDS Recommended Practice) by the end of CY2009 and to simultaneously begin the necessary program of SSI standards development.

6. Important Event: NASA DTN-for-2010 Project • NASA DTN-for-2010 Project • Goal: get DTN (RFC5050) to TRL-8 by 2010 • DINET Flight Experiment imminent

7. WG Questions[Don’t try to answer now, come back to these later] • Do we all agree with our current charter? • Scope • Work items • Are we tasked with: • Justifying the need for store-and-forward networking in space • Providing an architecture for in-space cross-support • Providing an architecture would presumably include CSS plan, “proto-cross-support-agreement” plan, network management protocol, routing protocol

8. Review of Current Green Book Draft Show of hands: who’s read it?

9. Summarization of JAXA1 comments on draft Green Book • Some missions use hundreds of levels of priority • Some missions use dynamic priority (high priority for thruster data after maneuver) • CFDP flow-label-like ‘priority marker’? • Modify priority based on time data is generated • Possibly use management protocol to modify ‘relative priority’ of bundles sitting in a relay • Desire a “bundle sequence number” to detect missing bundles • A bundle management protocol • 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. • BP / LTP linkeage • Could the bundle protocol ‘reactively fragment’ bundles that are partially received?

10. Keith’s Reactions to JAXA Comments • Thanks! • Priorities • Additional levels of priority could be implemented in an extension block (akin to a secondary header) • Applications sending data get to set priority, so dynamic priority could be supported (provided the application knows the correct priority to set) • Differential treatment of bundles based on creation time: really difficult to do far from the source – can’t be a function of the (possibly extended) priority? • Bundle sequence number • I think this is supported by RFC5050. The creation time sequence # MUST be monatone increasing within each second… (not necessarily reset every second) • Bundle management protocol • Definitely • I favor a priority-based approach over a flow-label one • Reactive fragmentation • Yes, we’ve thought of that and should be able to implement it

11. ESA1 Summary Comments on Draft Green Book • Suggest that the Green Book needs to (chronologically): • Examine present scenarios in more detail with a view to justifying the need for DTN • Provide a more general description of DTN • Discuss in more detail present key capabilities (IP, Packet, CFDP, links (reliable forward and prox-1 and unreliable TM) • Describe a reference DTN scenario (where we want to get to ) • Indicate the `transition path’ • Present detailed DTN scenarios (present section 4) and issues

12. ESA1 Detailed Comments 2. Rational and background The case is not really made for networking, nor DTN for that matter, so the 6th paragraph - “while terrestrial networking ….” - comes out of nowhere, as does section 2.2 More emphasis should be placed on the increase of cooperative missions and the use of multiple assets providing a network based scenario. We probably need to have a couple of pictures showing current managed systems (with f ew elements) and the transition to future (multi element) scenarios which will be difficult/expensive to manage using manual techniques. At the moment there is no real description of what DTN is and it’s just assumed that DTN is available and known to the reader. I think there should be a more general overview of DTN up front before getting into the details of section 3 and 4. 3. Requirements and desired characteristics This section takes for granted that we need a network layer service and accompanying protocols but with very little preceding explanation. I think we first need to describe the existing systems in terms of current protocol stacks and usage before assuming we have a need for a network layer service and DTN. I guess we need to examine the shortcomings of the present systems when applied to future missions (lack of addressing capability in the space packet, manually managed/fixed routes). Thepresent applications should also be described, shadowing the examplescurrently given in section 5. An addressing function is missing from the list of requirements and desired characteristics? Application PDU size – I guess we are talking about files here but these will be broken down into manageable chunks by, for example CFDP. Should probably refer to Application layer SDUs? 4.1 The example in figure one is depicting 4 relays. This may be valid in the far future but not as a realistic example of the next batch of missions. At least the scenario should be match to something more tangible – Multi mars obiter to mars lander to mars rover. In general, the examples are based on rather advanced scenarios which may be fine to demonstrate the capabilities of DTN but may not be the best in a Green book where we are trying to convince others of the need for DTN to support foreseeable missions. Section 5 I think we should be selling the use cases on the basis of real mission needs rather than on Use cases for DTN as seems to be implied by the opening sentence. 5.2 Would prefer to see a packet based example for low level commanding rather than the frame level one currently shown. Figure 6 on the CFDP evolution path introduces a bunch of stuff that has not been discussed previously (bundles, LTP, ..) in the document and also takes an “odd” configuration for how it is practically used today. The messaging capability of CFDP is not mentioned but AMS suddenly appears. IP is only present on current systems and not in the IP example (ok by me but a bit odd).

13. Keith’s Reactions to ESA1 Summary Comments • Uh,….Thanks.  • Can the following be achieved (at least to a large degree) by citing existing documents: • Examine present scenarios and present need for DTN • Cite SISG Report? • Provide a more general description of DTN • Cite RFC5050 and published material on DTN and Interplanetary Internet • Discuss in more detail present key capabilities (IP, Packet, CFDP, links (reliable forward and prox-1 and unreliable TM) • Current CCSDS capabilities should be described in relevant CCSDS documents?

14. Green Book Rev 2 • Try to pull information out of the WG wrt Green Book Material • Need for a space internetworking protocol • Requirements for a space internetworking protocol • Scenarios (a la CFDP scenarios) • Can these requirements be met with: • CCSDS Space Packets • CFDP (as a network protocol)? • [It’s not that I don’t think IP is applicable, but in the CCSDS context, it’s as new as DTN] • What additions / modifications would be needed in order for the above protocols to meet the requirements • Can these requirements be met with RFC5050 • What additions / modifications would be needed

15. Slide to write down all the insightful inputs from the WG for Rev2

16. Other Specific Comments?

17. Space DTN Requirements • [Fill in during meeting.] • From the 0.2 Draft • OSI Layer-3/4 protocol • Be clear that DTN provides a layer 3-4 service interface to applications (and we can call the layer-4 part end-to-end) • Arbitrarily-size application PDUs • Works when the underlying fabric is delayed / disrupted • Asymmetric / one-way links • Temporary network partitions (but with eventual bi-directional connectivity – there will eventually be a return path) • Provides data accountability • RFC5050 supports ‘reports’ • Need for integrity check on data reported • “Critical bundle” flag set by application to ‘flood’ bundle. Bundle is forwarded over all interfaces that have a path to the destination. • Provides optional reliability • Option to request that only reliable underlying convergence layer protocols be used • Provides data priority mechanism • DTN provides 3 levels, JAXA, ESA, JPL want more (~order 100) • Can run over all CCSDS data links

18. Security Requirements • Authentication of participants • On the ground • To the control center • To a particular console • To a particular controller • On the spacecraft • Authenticate the S/C, the instrument • How do we find out what the requirements are? • And then how would we try to meet them with DTN capabilities? • Encryption

20. Hop-by-hop authentication / access control (Bundle Authentication Block – BAB) • Verification that stuff you send me is really from you and good stuff • Intended to protect the network from denial of service attacks (flooding with bad data) • End-to-end security (Payload Integrity Block, Payload Confidentiality Block) • Authentication • Integrity • Confidentiality • Access control?

21. DTN DTN UDP TCP UDP TCP

22. Cross-support at DTN • Interoperability below DTN (not necessarily cross-support) DTN DTN rest rest Example: not all prox-1 ports are ‘supported’ across a cross-support interface Conformance: Interoperability: Cross-support: [get w/ CSS area]

23. Mission Control Ground Station Mars Relay Satellite Mars Rover CT CT Application Application CT CT DTN DTN (potential delay) DTN (Potential delay) DTN TCP TCP LTP LTP LTP LTP IP Router Encap Encap Encap Encap IPv6 IPv6 IPv6 Ethernet ATM Ethernet ATM UTP DS-1 AOS AOS Prox-1 Prox-1 UTP DS-1 Terrestrial Network Deep Space Orbit-to-Surface Persistent Storage CT Custody Transfer Capability Bundle Path Custody Acknowledgements

24. CCSDS Space Packet as DTN Internetwork Protocol [Fill in at meeting.]

25. CFDP as Space Internetwork Protocol [Fill in at meeting.]

26. RFC5050 Capabilities The Bundle Protocol provides an ISO layer-3 networking service 3 Priorities End-to-end security Hop-by-hop security

27. Documents to Produce Green Book DTN Protocol Specification Interfacing DTN to CCSDS link layers (LTP)

28. CONCLUSIONS

29. Those Questions Again… • Do we all agree with our current charter? • Scope • Work items • Are we tasked with: • Justifying the need for store-and-forward networking in space • Providing an architecture for in-space cross-support • Providing an architecture would presumably include CSS plan, “proto-cross-support-agreement” plan, network management protocol, routing protocol

30. Goals for Next Meeting Cycle • Complete Green Book • Will probably require interim telecons and maybe meetings • Move forward with testing / testbeds / interoperability • Additional implementations

31. Volunteers • Requirements for DTN capabilities • Security • Mission use cases for DTN

32. You have reached the last page of this presentation. Go outside and explore the city.