sis deep space protocols status
Post on 22-Jan-2016
36 Views
Preview:
DESCRIPTION
TRANSCRIPT
17 November 20041
Scott Burleigh, JPL
SIS Deep SpaceProtocols Status
17 November 20042
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.
17 November 20043
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.
17 November 20044
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.
17 November 20045
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.
LTP point-to-pointretransmission
Bundling store-and-forward
TM TC Prox-1
R/F, optical
TCP “point-to-point”retransmission
Ethernet
IP
wire
AOS
17 November 20046
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.
17 November 20047
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.
17 November 20048
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 Delay-Tolerant Networking (DTN) bundling protocol.
• Standard class-1 CFDP over reliable Bundling UT layer.
17 November 20049
Network Deployment
Rover1Rover2 Motes
Lander1
Orbiter2Orbiter1
Ground Station
Investigator
Earth’sInternet
DeepSpaceBackbone
MarsIn-situInternet
Bundle
CFDP
Bundle
CFDP
Bundle
CFDP
Bundle
CFDP
MarsRelayNetwork
MarsSensorWeb
Bundle
Bundle
17 November 200410
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.
17 November 200411
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.
17 November 200412
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.
17 November 200413
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.
17 November 200414
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.
17 November 200415
CFDP/DTN Architecture
(no retransmission, no store-and-forward)
User application
UT adapter
CFDP file system functions
“UT layer”
CFDP unacknowledged transmission
LTPpoint-to-point
retransmission
Bundling store-and-forward
TM/TC, AOS Prox-1
R/F, optical
TCP end-to-endretransmission
Ethernet
wire
COP/Pretransmission
IP network routing
7
4
3
2
1
(bandwidth management)
17 November 200416
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.
17 November 200417
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 November 200418
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 1995-1996; 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.
17 November 200419
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.
17 November 200420
Deep Space Communications Architecture
(no retransmission, no store-and-forward)
User application
UT adapter
CFDP file system functions
“UT layer”
CFDP unacknowledged transmission
LTPpoint-to-point
retransmission
Bundling store-and-forward
TM/TC, AOS Prox-1
R/F, optical
TCP end-to-endretransmission
Ethernet
wire
COP/Pretransmission
IP network routing
7
4
3
2
1
(bandwidth management)
AMS
UT adapter
top related