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

2 Revised Agenda  Review SIS-DTN charter and work plancharter  Review of Spring 2008 meeting and significant events Work items out of Spring meeting SISG / IOAG presentation SISG NASA DTN-for-2010 work  Green Book Review Green Book Goals Comments Direction / next steps Volunteers  Long Erasure Codes Presentation  RFC5050 Discussion RFC5050 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 DATE

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 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. DATE

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 DATE

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. DATE

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 DATE

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 DATE

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

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? DATE

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 DATE

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 DATE

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). DATE

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? DATE

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 RFC What additions / modifications would be needed DATE

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

16 Other Specific Comments? DATE

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 DATE

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 DATE

19 DATE

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? DATE

21 DATE DTN UDPTCP DTN UDPTCP

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

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

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

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

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

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

28 DATE 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 DATE

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 DATE

31 Volunteers  Requirements for DTN capabilities Security  Mission use cases for DTN DATE

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