Informationssysteme in der Raumfahrt. Transport Protocols and Applications for Internet Use in Space

Transkript

1 Informationssysteme in der Raumfahrt Transport Protocols and Applications for Internet Use in Space

2 Gliederung Internet Protokolle im Weltraum Transport Layer Application Layer Transportprotokolle im Weltraum IP basierte Operationen und Missionsszenarien Derzeitiger Stand und Ausblick

3 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

4 Internet Protokolle im Weltraum f

5 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

6 Transport Layer f Klassische Protokolle: UDP (User Datagram Protocol) RFC-768 RTP (Realtime Transport Protocol) RFC 1889 TCP (Transport Control Protocol) RFC-793

7 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

8 UDP f bevorzugt für Deep Space Missionen Flusskontrolle und Transportzuverlässigkeit müssen von der Application Layer implementiert werden

9 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

10 RTP f

11 TCP verbindungsorientiert Verbindungsauf - und Abbau (3 - Way Handshaking Algorithmus)

12 TCP f Funktionen: Multiplexing Übertragung in Segmenten (TCP Data Packet) mit max. Grösse von Byte Flow Control (Paketreihenfolge bleibt erhalten) Out - of - Band handling für Nachrichten hoher Priorität Zuverlässige Datenübertragung

13 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

14 TCP f

15 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

16 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) D max = Window Size/RTT

17 TCP f (angenommene Window Buffer Size = 8192 Byte) RTT D max 40 ms 240 ms 1666 ms 1600 kbit/s 266 kbit/s 38 kbit/s

18 TCP f Problem: größere RTT senkt Durchsatz Window Buffer muss heraufgesetzt werden 64 KByte Window Size ist problematisch T3 - Leitung mit Mbps RTT = 50ms (transkontinentales Kabel) Paketausgabe in 12 ms Spacecrafts müssen fähig sein größere Window Sizes auszudrücken

19 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)

20 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

21 TCP f

22 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)

23 TCP f Für TCP gilt: Paketverlust durch Congestion = Paketverlust durch Noise je mehr Noise, desto mehr Retransmission Timeouts

24 TCP Tuning Window Scale Skalierfaktor erlaubt das Feld Window Size um 16 Bit nach links zu shiften 2 32 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

25 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)

26 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

27 Application Layer f

28 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

29 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)

30 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

31 TCP Applikationen f Reliable File Transfer FTP komplex zu implementieren HTTP sehr einfach zu implementieren persistente Verbinding Verbindungs Auf- und Abbau

32 TCP Applikationen f 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

33 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

34 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)

35 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

36 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

37 Noise Transportprotokolle im Weltraum f 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)

38 TCP/PEACH ECN SACK Transportprotokolle im Weltraum f machen TCP weniger noiseanfällig

39 Transportprotokolle im Weltraum f Einschränkungen Power CPU Bandwidth (uplink vs. downlink) IP Header Compression ( every bit is precious Deep-Space) Cellular-IP

40 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

41 Transportprotokolle im Link Asymmetrie Weltraum f 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

42 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

43 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)

44 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)

45 Derzeitiger Stand und Ausblick f

46 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

47 Derzeitiger Stand und Ausblick f

48 Derzeitiger Stand und Ausblick f UoSAT-12: Off-the-shelf FTP Client Applikation mit packet trace

49 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)

50 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

51 Transport Protocols and Applications for Internet Use in Space