Kontrolle von engineering, housekeeping und commanding data

Informationssysteme in der Raumfahrt
Transport Protocols and Applications
for Internet Use in Space
Gliederung
•
•
•
•
•
•
Internet Protokolle im Weltraum
Transport Layer
Application Layer
Transportprotokolle im Weltraum
IP basierte Operationen und Missionsszenarien
Derzeitiger Stand und Ausblick
Internet Protokolle im Weltraum
• OMNI Projekt:
– Ziele:
• End - to - End Network (transparente Verbindung)
• Referenzsystemarchitektur
• COTS
– Architektur:
• IP basiert Î end - to - end Konzept realisiert
• Schichtenarchitektur Î ISO/OSI
Internet Protokolle im Weltraum
f
Transport Layer
• logisches multiplexen von Paketen (Ports)
– versenden von asynchronen Daten über einen
physischen Link
– Insgesamt 65,535 „virtuelle“ Kanäle
– Network Layer handelt Prioritäten
– Grosse Anzahl von Application ID‘s allein in Bezug
auf Telemetriedaten
Transport Layer f
• Klassische Protokolle:
– UDP (User Datagram Protocol) Î RFC-768
– RTP (Realtime Transport Protocol) Î RFC 1889
– TCP (Transport Control Protocol) Î RFC-793
UDP
• verbindungslos, kein Handshaking
• Funktionen:
– Fehlererkennung
– Multiplexing
ÎReihenfolge der gesendeten Pakete nicht garantiert
Îschelle Übertragung („send and forget“)
• geringen Overhead (8 Byte)
• Delay – insensitiv
• geeignet für unidirektionale, hochgradig asymmetrische
Verbindungen
UDP f
• bevorzugt für Deep – Space Missionen
• Flusskontrolle und Transportzuverlässigkeit müssen von
der Application Layer implementiert werden
RTP
• wird generell „on top of“ UDP implementiert
• Funktionen:
– end - to - end Übertragung von Daten mit „real - time“ Charakter
(streaming audio, video) Î isochrone Daten
• zusätzliche 12 Byte Overhead
• Services:
–
–
–
–
–
Timestamping
Sequence Numbering
Delivery Monitoring
Payload Identifikation
VoIP
RTP f
TCP
•
verbindungsorientiert Î Verbindungsauf - und Abbau
(3 - Way Handshaking Algorithmus)
TCP f
• Funktionen:
– Multiplexing
– Übertragung in Segmenten (TCP – Data – Packet)
mit max. Grösse von 65.535 Byte
– Flow Control (Paketreihenfolge bleibt erhalten)
– „Out - of - Band“ handling für Nachrichten hoher
Priorität
Zuverlässige Datenübertragung
TCP f
• Übertragungsweise:
– Sender startet einen Timer nach versenden eines
Segmentes
– bei korrekter Übertragung sendet Empfänger eine
positive Bestätigung (ACK)
– Timeout: Sender überträgt von Neuem
• 20 Byte Overhead
• Delay - sensitiv
TCP f
TCP f
• Einsatz:
– Download von Instrumenten Daten
– Upload von Spacecraft oder Instrumenten
Commandos
• „Level-0 processing“, zuverlässiger Transfer von
Daten die für den Betrieb notwendig sind
TCP - Limitations
• Wichtige Parameter für Datendurchsatz:
– Window Size (Î Flow Control)
• Anzahl der Bytes die empfangen werden können
• WS = 0: Paket mit „Acknowledgement Number - 1“ wurde
empfangen Î Puffer voll
– RTT (Round Trip Time)
Dmax = Window Size/RTT
TCP f
(angenommene Window Buffer Size = 8192 Byte)
RTT
Dmax
40 ms
1600 kbit/s
240 ms
266 kbit/s
1666 ms
38 kbit/s
TCP f
• Problem:
– größere RTT senkt Durchsatz Î Window Buffer
muss heraufgesetzt werden
– 64 KByte Window Size ist problematisch
• T3 - Leitung mit 44.736 Mbps
• RTT = 50ms (transkontinentales Kabel)
ÎPaketausgabe in 12 ms
• Spacecrafts müssen fähig sein größere Window
Sizes auszudrücken
TCP f
• Problem:
– TCP – Überlastungsüberwachung
(Congestion Control)
• TCP ursprünglich für Festnetze konzipiert
• kaum Übertragungsfehler, ausgereifte Software
• Paketverlust durch Netzüberlastung
ÎCongestion Window
• maximale Anzahl von Bytes die gesendet werden
können: min(CW, RW)
TCP f
• Congestion Window hat anfänglich die Größe des
maximalen Segments
• Bei erfolgreicher Übertagung:
CW = CW + „Anzahl der erhaltenen ACK‘s in Byte
Î exponentielles Wachstum bis Schwellenwert
(Threshold) erreicht ist (anfangs 64 KByte)
• ab Threshold nur noch lineares Wachstum
• Timeout: „Slow Start“ - Algorithmus
TCP f
TCP f
• es existieren 2 Gründe für das Herabsetzen des
Schwellenwertes (bzw. Einsatz von Slow Start)
– Lücke im Datenstrom (Paketverlust oder kurzfristigen
Stau)
• korrekte Übertragung bis zum dem als letztes bestätigten
Paket Î mehrfaches Senden der selben ACK
• Slow Start nicht gerechtfertigt
– Fehlende Bestätigung (Timeout)
TCP f
• Für TCP gilt:
Paketverlust durch Congestion
=
Paketverlust durch Noise
Î je mehr Noise, desto mehr Retransmission Timeouts
TCP Tuning
• Window Scale
• Skalierfaktor Î erlaubt das Feld Window Size um 16 Bit
nach links zu shiften Î 232 Bit möglich
• Fast Retransmit und Fast Recovery
• Timout zu lang Î nach dem 3 doppelten ACK wird „Fast
Retransmit“ aktiviert (problematisch bei mehrfachem
Paketverlust)
• Fast Recovery verhindert ungerechtfertigten Einsatz von
Slow Start Î Congestion Window wird nicht verkleinert
TCP Tuning f
• SACK (Selective Acknowledgement)
• Bisher kumulative Bestätigung Î Empfänger kann nun
einzelne Pakete bestätigen, so dass der Sender
ausschließlich verlorene Daten erneut sendet
• Snooping TCP
• Mithören von Daten und Bestätigungen, lokale
Übertragungswiederholung
• SNACK (selective negative ACK)
Application Layer
• Standard Protokolle:
•
•
•
•
Aber:
HTTP
FTP
SMPT
Telnet
etabliert, ausgereift Î COTS
erfüllen Anforderungen vieler Missionen
• weniger flexibel als selbst definierte Protokolle, jedoch
Interoperabilität garantiert!
Für jede Mission muss aufgrund ihrer Anforderungen bzw.
Trade-Offs bzgl. Kosten/Nutzen die Entscheidung neu getroffen
werden
Application Layer f
UDP Applikationen
• UDP basiert App‘s:
– Simple Data Delivery
• CCSDS (Consultatvie Committee of Space Data
Systems) Paketformat eingebettet in UDP
• Erfüllt den Zweck eines selbstdefinierten
Protokolls, welches Applikations – spezifische
Daten (Telemetrie, Command) kapselt
UDP – Applikationen f
• Reliable File Transfer
– CSSDS File Delivery Protocoll (CFDP)
– MFTP (Multicast File Transfer Protocol)
– PBP (Pipe Binding Protocol)
• Time Synchronisation
– NTP (Network Time Protocol)
TCP Applikationen
• Reliable Simple Data Delivery
• Applikation muss Pakete mittels selbst definiertem Protokoll
kapseln
– Unterschied zu UDP:
• TCP übernimmt Fehlererkennung und
Übertragungswiederholungen
– vergleichbar mit CCSDS COP – 1
(Command Operation Protocol – 1)
• Kommando Verifikation durch CCSDS Filter
TCP Applikationen f
• Reliable File Transfer
FTP
HTTP
komplex zu implementieren
sehr einfach zu implementieren
persistente Verbinding
Verbindungs Auf- und Abbau
TCP Applikationen f
• Email
– SMTP (Simple Mail Transfer Protocol)
• wohl am weitesten verbreitetes Tool zum
Versenden von Nachrichten zwischen TCP/IP
Hosts
• handelt auch binären Daten
• end - to - end Übertragung
• „Mail – Gateways“ Î „Store and Forward“
TCP Applikationen f
• Kommandos und Daten könne auch dann „gesendet“
werden, wenn kein Kontakt besteht
• Î „Batch“ bzw. „Bundled“ Mode ermöglicht
automatisches „Queuing“ und späteren Transfer
wenn Kontakt wiederhergestellt
• sehr günstige Realisierung mittels OTS - Software
Transportprotokolle im
Weltraum
„The environment for the Internet is basically no
delays, no errors, continuous connectivity, and
pretty symmetric data transfer. If you look at the
space enviroment, it‘s almost completely
reversed. There are high delays and high error
rates. The links are not continuous or
symmetric.“
(Space News)
Transportprotokolle im
Weltraum f
• Verzögerungszeiten
– UDP: Delay-unabhängig
– TCP: Delay-abhängig
– LEO Î RTT 4ms-32ms
– GEO Î RTT ~240ms
Î TCP/IP erfolgreich verwendet mit 400Mbps
Transportprotokolle im
Weltraum f
• TCP abhängig von Bandbreite/Verzögerungszeit
Î low-bandwidth/high delayÍÎhigh-bandwidth/low delay
• Grenze für TCP-Applikationen bei 1666ms
(Monddistanz)
Î UDP basierte Protokolle wie MFTP, PBP, CFDP für
Deep - Space
Transportprotokolle im
Weltraum f
• Noise
– UDP nicht betroffen
– TCP betroffen aufgrund Congestion Control
– BER (Bit-Error-Rate) von RF ~ 10-5
(Dial-Up Telefonverbindung mit EC erreicht 10-7)
– BER von 10-7 Vorraussetzung für Handshaking
Protokolle (z.B. TCP/IP)
Transportprotokolle im
Weltraum f
• TCP/PEACH
• ECN
• SACK
machen TCP
weniger
noiseanfällig
Transportprotokolle im
Weltraum f
• Einschränkungen
– Power
– CPU
– Bandwidth (uplink vs. downlink)
• IP Header Compression
(„every bit is precious“ Î Deep-Space)
• Cellular-IP
Transportprotokolle im
Weltraum f
• Verbindungsmanagement/Routing
– LEO:
• typische Kontaktzeit 8-15 Minuten
• QoS ist abhängig von der Anzahl der
Bodenstationen
• Verbindungsmanagement ähnlich wie bei
mobilen Computern am Boden Î Mobile IP
Î M - TCP als als mobiles Transportprotokoll
Transportprotokolle im
Weltraum f
• Link – Asymmetrie
• downlink Bandbreite > Uplink Bandbreite
• teilweise Asymmetrien von 1000:1
• Bandbreite für Empfangsbestätigungen begrenzen
Durchsatz der Nutzdaten in umgekehrter Richtung
• TCP:
– Durchsatz wird erst ab 50:1 beeinfluss (8 kbps Uplink
entsprechen 400 kbps downlink)
• UDP:
– Downlink Durchsatz wird nicht beeinflusst
IP basierte Operationen und
Missionsszenarien
• Kontrolle von engineering, housekeeping
und commanding data
– UDP/IP: unidirektionale Verbindung, kurze
Kontaktzeit, lange RTT, Notfallsituationen
Î real-time commanding
– TCP/IP: bidirektionale Verbindung, längere
Kontaktzeit, kurze RTT Î garantierter Transfer
– SMTP über IP: store and forward commanding von
command loads
IP basierte Operationen und
Missionsszenarien f
• Auf IP-basierende Protokolle unterstützen
weitere komplexe Szenarien:
– Formationsflug, Driftkontrolle
– Intersatellitenkommunikation bei
Nanosatelliten, spacecraft cross-support
– Ad-Hoc Kollaborationen
– Robortersteuerung (habtische Interfaces)
Derzeitiger Stand und Ausblick
• On-Orbit Clock Synchronisation mit NTP
– NTP Client auf UoSAT-12
– US Naval Observatory timeserver
(worst-case-Szenario mit 20 Routerhops)
– 2 Testverfahren:
• Network delay (NTP time change disabled)
• Offset Berechnung (NTP time change enabled)
Derzeitiger Stand und Ausblick f
Derzeitiger Stand und Ausblick f
• Download via FTP
– Landsat-7:
• Starke FEC (BER ~10-9)
• große Bodenantennen
Î trotzdem Verlust von Bilddaten aufgrund von
Noise da keine Übertragungswiederhohlung
Derzeitiger Stand und Ausblick f
Derzeitiger Stand und Ausblick f
– UoSAT-12:
• Off-the-shelf FTP Client Applikation mit packet
trace
Derzeitiger Stand und Ausblick f
• speziell für den Weltraum angepasste Protokolle auch
bekannt als „Space Communications Protocolls
Standards“ (SCPS)
– Erweiterung für TCP: SCPS-Transport Protocol (SCPS-TP)
– ausgerichtet auf Problematik der Satellitenumgebung:
•
•
•
•
•
•
•
•
lange Delaypfade
grosse Bandbreite/Delay Produkte
grosse Übertragungsfenster
begrenzte Link Kapazität
Verbindungsassymetrie
variierende RTT‘s
Übertragungsfehler
periodisch wechselnde Verbindungen (handoffs und Ausfall)
Derzeitiger Stand und Ausblick f
• zukünftig relevante Probleme:
– Sicherheitslösungen basierend auf IP wie Ipsec und
VPN (Virtual Private Network)
– Mobile IP und DHCP
– Steigerung der Übertragungseffizienz für Deep-Space
Szenarien
– Optimierung von Congestion Control Algorithmen
Transport Protocols and Applications
for Internet Use in Space