1DATE

SIS-DTN WG Meeting

October 16, 2008Berlin, 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

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

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 RFC5050- 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

19DATE

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

21DATE

DTN

UDP TCP

DTN

UDP TCP

22DATE

DTN 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]

23DATE

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

GroundStation

Deep Space

DTN (Potential delay)

LTP

Encap

AOS Prox-1

Mars RelaySatellite

IP Router

ATM

DS-1

Persistent StorageCT Custody Transfer Capability

Bundle PathCustody Acknowledgements

CT CT CT CT

MissionControl

MarsRover

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 PrioritiesEnd-to-end securityHop-by-hop security

DATE

27

Documents to Produce

Green Book

DTN Protocol Specification

Interfacing DTN to CCSDS link layers (LTP)

DATE

28DATE

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