SIS Deep Space Protocols - inc AMS

Download Report

Transcript SIS Deep Space Protocols - inc AMS

SIS Deep Space
Protocols Status
Scott Burleigh, JPL
1
17 November 2004
Overview
• CCSDS File Delivery Protocol (CFDP)
– Unacknowledged CFDP Extensions (UCE) pink sheets were issued
for review and agency approval on 19 October 2004.
– Max Ciccone will report on progress in interoperability testing.
• Delay-tolerant networking (DTN)
– BOF meets for the first time in November of 2004.
• Licklider Transmission Protocol (LTP)
– A link-neutral point-to-point retransmission system designed to
support DTN operations in deep space.
– BOF will be proposed later this week.
• Asynchronous Message Service (AMS)
– A companion protocol to CFDP, for message exchange over the
deep space delay-tolerant network.
– BOF will be proposed later this week.
2
17 November 2004
CFDP UCE (1 of 2)
• Motivated by processing requirements for Mars Reconnaissance
Orbiter (MRO): MRO wants to run CFPD in unacknowledged
mode over a reliable UT layer, in this case a non-standard AOS
frame retransmission system.
• Problem:
– Version B2 of CFDP closes an unacknowledged-mode transaction
as soon as the EOF PDU is received.
– But a reliable UT layer might cause missing file data PDUs to be
retransmitted after EOF receipt. Because the transaction is closed,
these PDUs would never be collected into the delivered file.
• Solution: add a “check timer” that works in unacknowledged
mode the same way the NAK timer works in acknowledged
mode. Transaction is closed only when examination finds that
reception is complete – either on EOF arrival or on check timer
expiration – or when check timer expiration limit is reached.
3
17 November 2004
CFDP UCE (2 of 2)
• Status:
–
–
–
–
–
–
BOF formed in May of 2003 and agreed on design.
Working group approved in October of 2003.
Implementation demonstrated in February of 2004.
Initial pink sheets completed in March of 2004.
Revised pink sheets completed in May of 2004.
Pink sheets issued for agency review and approval on 19 October
2004.
4
17 November 2004
Delay-Tolerant Networking (DTN)
• General-purpose capability for scalable, reliable communications
across deep space.
• Extending and streamlining the capabilities of CFDP:
– Built-in security (authentication and confidentiality).
– Flexible, dynamic multipath route selection.
– Deferred transmission, store-and-forward routing for tolerance of
intermittent connectivity.
– Point-to-point retransmission for efficient reliability.
– Custody transfer for early release of retransmission resources.
• Will enable CFDP to scale up to large deployment
configurations.
Bundling store-and-forward
TCP “point-to-point”
retransmission
LTP point-to-point
retransmission
TM
TC
AOS
IP
Prox-1
R/F, optical
Ethernet
wire
5
17 November 2004
CFDP Basic Deployment
• Premise: entities can communicate directly (R/F or optical).
– Mutual line-of-sight visibility.
– Compatible operating schedules: entity A can point at entity B and
transmit at a time when entity B can point at entity A and receive.
– Adequate links: the levels of transmitter power and receiver power
combine to produce a data rate greater than zero.
• Implementation: core CFDP over CCSDS TM/TC (or AOS) UT
layer.
6
17 November 2004
CFDP Advanced Deployment
• Premise: entities cannot communicate directly.
– No mutual visibility: intervening planetary mass, intervening Sun.
– Incompatible operating schedules.
– Insufficient signal power between sender and receiver.
• So CFDP must support indirect communication, via “relay” or
“waypoint” entities, using store-and-forward techniques.
• Constraint: a single, serial end-to-end route from the sender to
the receiver for the duration of each transaction.
• Implementation options:
– Extended procedures
• Additional functionality built into CFDP itself.
– Store-and-forward Overlay
• CFDP is left unchanged.
• Additional functionality built into standard user application layer.
7
17 November 2004
CFDP Network Deployment
• Premise:
– As in Advanced Deployment, entities cannot communicate directly.
– But the constraint on Advanced Deployment is removed: multiple
forwarders may operate in parallel for a single CFDP transaction.
• So data may routinely arrive out of transmission order.
– Bad for end-to-end acknowledged CFDP: whenever EOF arrives
before file data segments, unnecessary retransmission is triggered.
• Implementation: core unacknowledged CFDP over DelayTolerant Networking (DTN) bundling protocol.
• Standard class-1 CFDP over reliable Bundling UT layer.
8
17 November 2004
Network Deployment
9
17 November 2004
Bundling
• As in the Internet, there may be multiple possible routes (both in
space and time) to the destination.
• Multi-layer routing:
– End-to-end routes are computed by “bundling” protocol.
– Route to next hop within the same region – if not point-to-point – is
performed by region-specific protocol, such as IP within the Internet.
• Internal routing technology can be different in different regions.
– Tuned for cost effectiveness.
– Evolving independently.
– This enables end-to-end routing complexity to scale up indefinitely
without imposing excessive overhead within any single region.
10
17 November 2004
Bundling (cont’d)
• Bundle forwarding algorithms may consider:
– requested delivery deadline
– estimated time to destination on alternative paths
– class of service, e.g., explicit transfer of custody
• For example, bundling might withhold bundles from an
impending low-rate contact in favor of a future high-rate contact.
• Routing decisions are re-evaluated at each forwarding hop.
Nature of connectivity may affect routing decisions:
– continuous
– opportunistic
– scheduled
• Schedules loaded via management interface or routing protocol.
11
17 November 2004
Bundling (cont’d)
• Additional features:
–
–
–
–
“Reply-to” address may differ from original source.
Optional interim progress reports (similar to SFO).
Optional end-to-end reception report, retransmission.
Support for multiple user applications:
• CFDP
• sensor webs
• messaging
– Explicit transfer of custody.
• Not all forwarding nodes need be custodians.
12
17 November 2004
LTP
• LTP is Licklider (or “Long-haul”) Transmission Protocol.
• Directly descended from CFDP Core reliability procedures, with
a few simplifications:
– It’s not file-oriented. LTP divides a block into segments for reliable
transmission. No filestore commands, no metadata. (File-oriented
mechanisms are left to CFDP, above bundling.)
– Indications analogous to EOF, Finished, Prompt, etc. are
combinations of bit flags in the standard header.
– The last segment of a block carries an “end of block” flag. There’s
no separate “EOF” segment, so a small block may be entirely
contained in a single segment.
– Negative acknowledgment segments are sent reliably, so there’s
nothing like the NAK timer cycle. All timeout intervals can be
computed from operational data: no guesswork.
– No transaction-specific Suspend and Resume, no flow labels.
13
17 November 2004
LTP (continued)
• What’s retained from CFDP core reliability procedures:
– Deferred transmission.
– Parallel transactions, with a transaction cancellation mechanism.
– Negative acknowledgment of missing data, positive
acknowledgment of critical (e.g., end of block) segments.
– Abstract interface to underlying transmission layer.
– Simple analogs to the Prompt and Keepalive mechanisms.
– All four “lost segment detection” options: deferred, prompted,
immediate, asynchronous.
– Link-specific Freeze and Thaw.
14
17 November 2004
CFDP/DTN Architecture
User application
CFDP file system functions
CFDP unacknowledged transmission
7
(no retransmission, no store-and-forward)
UT adapter
Bundling store-and-forward
(bandwidth management)
“UT layer”
TCP end-to-end
retransmission
4
IP network routing
3
LTP
point-to-point
retransmission
COP/P
retransmission
TM/TC, AOS
Prox-1
2
Ethernet
R/F, optical
wire
15
1
17 November 2004
DTN Status
• Spring of 2002: Internet Research Task Force research group
DTNRG formed to articulate DTN concepts.
• Summer of 2002: first demonstration of initial Bundling
implementation.
• March 2003: peer review of DTN architecture Internet Draft.
• May 2004: DARPA issues BAA (Broad Agency Announcement)
for its DTN research program.
• July 2004: version 01 of LTP Internet Draft published.
– Version 02 editing is in progress.
– Stephen Farrell is working on the first implementation.
• September 2004: version 03 of Bundling protocol spec Internet
Draft published.
• November 2004: initial meeting of CCSDS DTN BOF.
16
17 November 2004
Asynchronous Message Service (1 of 3)
• In addition to file transfer, event-driven asynchronous message
exchange may also be useful for deep space communications
with and among spacecraft :
– streaming engineering (housekeeping) data
– real-time commanding
– continuous collaborative operation among robotic craft
• NASA’s proposed new Command, Control, Communications,
and Information (C3I) architecture is based on this model.
• Challenges in large-scale asynchronous message exchange:
– Heterogeneity: platforms, security regimes, communication
environments, QOS requirements, performance requirements, cost
tolerance.
– Changing topology: requires autonomous discovery of
communication endpoints, automatic reconfiguration.
– Publish/subscribe message exchange model scales better than
client/server.
17
17 November 2004
Asynchronous Message Service (2 of 3)
• But most asynchronous message exchange systems are:
– proprietary, licensed products (e.g., TIBCO Rendezvous, NDDS)
rather than open international standards;
– not designed for operation on deep space robots.
• Proposed CCSDS Asynchronous Message Service (AMS)
standard is based on proven NASA technology: no commercial
licensing, designed for spacecraft flight operations.
• Tramel (Task Remote Asynchronous Message Exchange Layer)
was developed in JPL’s Flight Systems Testbed (FST) in 19951996; mature and stable since 1998.
–
–
–
–
Real-time spacecraft simulation in FST (1994-1999).
Software fault tolerance experiments at JPL (1998).
X-34 Integrated Vehicle Health Management testbed (2003).
Baselined for inclusion in C3I.
18
17 November 2004
Asynchronous Message Service (3 of 3)
• AMS features:
–
–
–
–
Platform-neutral, UT-layer neutral.
Designed to scale from very small to very large configurations.
Self-configuring and fault-tolerant, via silent “meta-AMS” protocol.
“Remote AMS” adaptations enable efficient, delay-tolerant
publish/subscribe capability over interplanetary distances.
• Status:
– Concept paper (tentative protocol specification) ready for review.
– Fully-functional, well-documented prototype (Tramel) has been
mature for six years.
19
17 November 2004
Deep Space Communications Architecture
User application
CFDP file system functions
AMS
CFDP unacknowledged transmission
7
(no retransmission, no store-and-forward)
UT adapter
UT adapter
Bundling store-and-forward
(bandwidth management)
“UT layer”
TCP end-to-end
retransmission
4
IP network routing
3
LTP
point-to-point
retransmission
COP/P
retransmission
TM/TC, AOS
Prox-1
2
Ethernet
R/F, optical
wire
20
1
17 November 2004