1 date sis-dtn wg meeting october 16, 2008 berlin, germany
Post on 30-Dec-2015
214 Views
Preview:
TRANSCRIPT
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
top related