Interplanetary Networking Issues Dai Stanton DTN working Group Input October 2009

ESA Requirements From recent studies: – ESA Mission Operations personnel have a strong requirement to manage queues in relay/intermediate nodes based on application layer content. E.g. Deleting or reordering the forwarding of individual files. This is because, unlike IP networks, mission circumstances may change whilst data is in transit. – Pre-emption is required at file level. – The interface between ESA mission and other users (e.g. PIs, POCC) must include an application layer safety firewall in the forward direction. – Direct TM/TC capability is always required at orbiter/lander interface. – Requirement for reliable downlink to POCCs with NAKS routed through MCC.

Requirements Implications Issues: – Disassociation of the DTN bundles from their application semantics means that, at relaying nodes, it is not possible to perform operations based on these semantics such as deleting data, re-ordering queues, pre-empting transmission or resolving resource conflicts. – In CFDP it is possible to identify which PDUs are associated with, for instance, which command file at all points in the transmission path. Implications: – Active application layer intervention is always needed at orbiter relay for direct TM/TC. – Active application layer intervention is always needed at MCC for safety firewall. – Active application layer intervention is always needed at all disjoint relays for content based queue management. – Active application layer intervention needed to integrate POCC NAKs into command stream. Conclusion: – Planetary Internetworking operations cannot be fulfilled purely by a network layer protocol.

DTN Advantages over Current Protocols DTN Advantages: – Consideration of security aspects such as authentication, confidentiality and data integrity; – Dynamic and static routing capabilities for rapidly reconfiguring networks; – Reactive fragmentation to use alternative onward relaying paths as they become available; – Integrated universal addressing applicable to all data types; However.... – Security can be added to CFDP by external mechanism; – Dynamic routing is not seen as a requirement in the foreseeable future; – Pro-active fragmentation at source is sufficient to cope with predictable orbital disruption; – Universal addressing is also inherent in CFDP and thus not an issue if we move to file based operations.

Regarding Earth Station Networks Commitment of data to an Earth Station would need to take account of the spacecraft visibility to the ES with sufficient margin to account for an unknown retransmission volume or risk data being held up at the station until the next contact. Earth station links to the MCC should be inherently available and treating them as subnetwork layer resources avoids this problem. There is no advantage in treating ES as custody transfer nodes and there is a big disadvantage with committing data, via CFDP or DTN, to a non-disjoint resource.

DTN Service and Application Layer Responsibilities BP provides a reliable data transfer service. However there are no guarantees on when or in which order data will arrive. It is therefore left to the user to provide additional sequencing mechanisms. BP gives no indication of data completeness or duplication deletion. It is up to the user application to provide mechanisms to decide whether at any point in a data set/stream, all previous data has been received and to detect and delete duplicate data. Dealing with these aspects in the end applications on and end-to- end, rather than hop-by hop, basis may prove costly in terms of risk, delay and efficiency. The GB, or indeed RFC5050, does not clearly define these service characteristics or perform any analysis of the end-to-end implications of the service. IP is designed to work in conjunction with transport layer and above protocols to provide a useable service to applications. DTN currently does not address these issues in a holistic manner.

Operating CFDP over DTN DTN architecture includes CFDP in end systems to provide filestore/user interfaces. How do fragmentation mechanisms in CFDP and in BP interact? Which class of CFDP? Class 1 does not provide confirmation but Class 2 incorporates retransmission which may adversely interact with BP reliability. Does DTN work over a service with the characteristics in the previous slide?

Conclusions Deployment of a Space Internetworking layer analogous to IP is superficially attractive. However: this cannot occur without consideration of the functionality and feasibility of accompanying protocols to provide a usable service; operational requirements mitigate against a simplistic solution when in-transit data may need to be manipulated, safety firewalls need to be put in place, direct TM/TC is required and end-to-end interaction between e.g. payload and POCC needs to be controlled. Consideration of these aspects is not evident in the Green Book or in the RFCs. All envisaged ESA internetworking requirements can be fulfilled using existing CCSDS recommendations.

Current Interplanetary Networking using existing CCSDS Standards

Proposed Interplanetary Networking Using DTN