Telekommunikationsdienste und –protokolle

Motivation für Mobile IP
Telekommunikationsdienste und –protokolle
— Mobilkommunikation —
Auswirkungen auf Vermittlungs- und
Transportschicht
Mobile IP
Wegewahl in Ad-hoc Netzen
Geänderte Transportprotokolle
Wegwahl
basiert auf IP-Zieladresse, Netzwerk-Präfix (z.B. 129.13.42) legt
physikalisches Subnetz fest
wird das Subnetz gewechselt, so muss auch die IP-Adresse
passend gewechselt werden (normales IP) oder ein spezieller
Routing-Eintrag vorgenommen werden
Spezifische Routen zum Endgerät?
anpassen aller Routing-Einträge, damit Pakete umgeleitet werden
skaliert nicht mit Anzahl der mobilen Geräte und u.U. häufig
wechselnden Aufenthaltsorten, Sicherheitsprobleme
Vielen Dank an Prof. Jochen Schiller (FU Berlin)
für diese Folien und das dazugehörige Buch
Wechseln der IP-Adresse?
je nach Lokation wird entsprechende IP-Adresse gewählt
wie sollen Rechner nun gefunden werden – DNS-Aktualisierung
dauert lange
TCP-Verbindungen brechen ab, Sicherheitsprobleme!
TKDP-SS01-6-2
Anforderungen an Mobile IP (RFC 2002)
Terminologie
Transparenz
mobile Endgeräte behalten ihre IP-Adresse
Wiederaufnahme der Kommunikation nach Abtrennung möglich
Anschlusspunkt an das Netz kann gewechselt werden
Kompatibilität
Unterstützung der gleichen Schicht 2-Protokolle wie IP
keine Änderungen an bisherigen Rechnern und Router
mobile Endgeräte können mit festen kommunizieren
Sicherheit
alle Registrierungsnachrichten müssen authentifiziert werden
Mobile Node (MN)
Knoten, der den Ort des Netzanschlusses wechseln kann,
ohne seine IP-Adresse ändern zu müssen
Home Agent (HA)
Einheit im „Heimatnetz“ des MN, typischerweise Router
verwaltet Aufenthaltsort des MN, tunnelt IP-Datagramme zur COA
Foreign Agent (FA)
Einheit im momentanen „Fremdnetz“ des MN, typ. Router
weiterleiten der getunnelten Datagramme zum MN, stellt meist auch
default-Router für den MN dar, stellt COA zur Verfügung
Effizienz und Skalierbarkeit
möglichst wenige zusätzliche Daten zum mobilen Endgerät (diese
ist ja evtl. über eine schmalbandige Funkstrecke angebunden)
eine große Anzahl mobiler Endgeräte soll Internet-weit unterstützt
werden
TKDP-SS01-6-3
Care-of Address (COA)
Adresse des für den MN aktuell gültigen Tunnelendpunkt
stellt aus Sicht von IP aktuelle Lokation des MN dar
kann z.B. via DHCP gewählt werden
Correspondent Node (CN)
Kommunikationspartner
TKDP-SS01-6-4
Beispielnetz
Datentransfer zum Mobilrechner
HA
HA
2
MN
MN
Router
Heimatnetz
Mobiles Endgerät
(physikalisches Heimat
Subnetz für MN)
Heimatnetz
Internet
Internet
FA
FA
Router
Fremdnetz
Fremdnetz
(aktuelles physikalisches
Subnetz für MN)
1
CN
CN
Endgerät
Sender
Router
TKDP-SS01-6-5
Datentransfer vom Mobilrechner
1. Sender sendet an IP-Adresse von MN,
HA fängt Paket ab (Proxy ARP)
2. HA tunnelt Paket an COA, hier FA,
durch Kapselung
3. FA leitet das Paket an MN weiter
TKDP-SS01-6-6
Netzintegration
HA
1
MN
Sender
Heimatnetz
Internet
FA
Fremdnetz
1. Sender sendet ganz normal an
IP-Adresse des Empfängers,
FA dient als Standard-Router
CN
Empfänger
3
Agent Advertisement
HA und FA senden periodisch spezielle Nachrichten über ihr
Vorhandensein in die jeweiligen physikalischen Subnetze
MN hört diese Nachrichten und erkennt, ob er sich im Heimat- oder einem
Fremdnetz befindet (Standardfall falls im Heimatnetz)
MN kann eine COA aus den Nachrichten des FA ablesen
Registrierung (stets begrenzte Lebensdauer!)
MN meldet via FA seinem HA die COA, dieser bestätigt via FA an MN
diese Aktionen sollten durch Authentifikation abgesichert werden
Bekanntmachung
typischerweise macht nun der HA die IP-Adresse des MN bekannt, d.h.
benachrichtigt andere Router, dass MN über ihn erreichbar ist
Router setzen entsprechend ihre Einträge, diese bleiben relativ stabil, da
HA nun für längere Zeit für MN zuständig ist
Pakete an MN werden nun an HA gesendet, Änderungen an
COA und FA haben darauf keinen Einfluss
Empfänger
TKDP-SS01-6-7
TKDP-SS01-6-8
Agent Advertisement
0
7
Typ
8
15
Registrierung
16
23
Code (0/16)
#Adressen
24
31
Prüfsumme
MN re
gist
ra
Erweiterung
zum ICMP
Router
Discovery
Adresslänge
Lebensdauer
Router Adresse 1
Präferenz 1
Router Adresse 2
Präferenz 2
tion
Typ (16)
Länge (6+4*n)
HA
MN re
HA
gist
ratio
re
regis
requ tration
est
...
tratio
regis
reply
n
que
st
n
tratio
regis
ly
p
e
r
n
t
tra
regis
reply
Sequenznummer
Lebensdauer der Registrierung R B H F M G V
COA 1
FA
tio
requ
est n
Reserviert
t
COA 2
Im Heimatnetz
Im Fremdnetz
...
TKDP-SS01-6-9
Mobile IP Registrierungsanforderung
0
7
Typ
8
15
16
S B D M G V rsv
23
24
TKDP-SS01-6-10
Kapselung
31
Lebensdauer
Heimatadresse
Heimatagent
originaler IP-Kopf originale Nutzdaten
COA
Identifikation
neuer IP-Kopf
Erweiterungen . . .
äußerer Kopf
neue Nutzdaten
innerer Kopf
originale Nutzdaten
Basiert auf UDP, Zielport 434
S: Simultaneous Bindings
B: Broadcast Datagrams
D: Decapsulation by Mobile Node
M: Minimal Encapsulation
G: GRE Encapsulation
V: Van Jacobson Header Compression
Lebensdauer: Gültigkeit der Registrierung in Sekunden (0=Deregistrierung)
TKDP-SS01-6-11
TKDP-SS01-6-12
Kapselung I
Kapselung II
Einkapseln eines Paketes in ein anderes als Nutzlast
z.B. IPv6 in IPv4 (6Bone), Multicast in Unicast (Mbone)
hier z.B. IP-in-IP-Kapselung, minimale Kapselung oder GRE (Generic
Record Encapsulation)
IP-in-IP-Kapselung (verpflichtend im Standard, RFC 2003)
Tunnel zwischen HA und COA
Minimale Kapselung (optional)
vermeidet die Wiederholung gleicher Felder
z.B. TTL, IHL, Version, TOS
kann nur bei unfragmentierten Paketen eingesetzt werden, da nun
kein Platz mehr für eine Fragmentkennung vorgesehen ist
Ver.
Ver.
IHL
TOS
Gesamtlänge
IP-Identifikation
Flags
Fragment Offset
IP-in-IP
TTL
IP-Prüfsumme
IP-Adresse des HAs
Care-of Adresse COA
Ver.
IHL
TOS
Gesamtlänge
IP-Identifikation
Flags
Fragment Offset
TTL
Schicht 4-Protokoll
IP-Prüfsumme
Originale Sender IP-Adresse des CNs
IP-Adresse des MNs
IHL
TOS
IP-Identifikation
Gesamtlänge
Flags
Min. Encap.
TTL
Fragment Offset
IP-Prüfsumme
IP-Adresse des HAs
Care-of Adresse COA
Schicht-4-Protokoll S
reserviert
IP-Prüfsumme
IP-Adresse des MNs
Originale Sender IP-Adresse (falls S=1)
TCP/UDP/ ... Nutzlast
TCP/UDP/ ... Nutzlast
TKDP-SS01-6-13
Generic Routing Encapsulation
• Checksum Present
• Route Present
• Key Present
• Sequence Number Present
• Strict Source Routing
• Recursion Control
äußerer Kopf
neuer Kopf
GRE
Kopf
TKDP-SS01-6-14
Optimierung des Datenpfades
originaler
Kopf
originale Daten
originaler
Kopf
originale Daten
Triangular Routing
Sender sendet alle Pakete via HA zum MN
unnötige Verzögerung und Netzlast
Lösungsansätze
Lernen des aktuellen Aufenthaltsorts von MN durch einen Sender
direktes Tunneln zu diesem Ort
HA kann einen Sender über den Ort von MN benachrichtigen
große Sicherheitsprobleme
neue Daten
Ver.
IHL
TOS
Länge
IP-Identifikation
Flags
Fragment offset
GRE
IP-Prüfsumme
IP-Adresse des HAs
Care-of Adresse COA
C R K S s Rec.
Rsv.
Ver.
Protokoll
Prüfsumme (optional)
Offset (optional)
Schlüssel (optional)
Sequenznummer (optional)
Routing (optional)
Ver.
IHL
TOS
Länge
IP-Identifikation
Flags
Fragment offset
TTL
Schicht-4-Protok.
IP-Prüfsumme
IP-Adresse des CNs
IP-Adresse des MNs
TTL
Wechsel des FA
Pakete „im Flug“ während des Wechsels gehen verloren
zur Vermeidung kann der neue FA den alten FA benachrichtigen,
der alte FA kann nun die noch ankommenden Pakete an den neuen
FA weiterleiten
diese Benachrichtigung hilft evtl. dem alten FA auch, Ressourcen
für den MN wieder freizugeben
TCP/UDP/ ... Nutzlast
TKDP-SS01-6-15
TKDP-SS01-6-16
Wechsel des Foreign Agent
Sender
HA
Data
FAalt
Reverse Tunneling (RFC 2344)
FAneu
Data
MN
HA
Data
Update
2
MN
ACK
Data
Data
Ortswechsel
des MNs
Update
Registration
Heimatnetz
Internet
ACK
Data
Data
Warning
FA
Data
Fremdnetz
Request
Update
ACK
CN
Data
Sender
1
3
Data
Empfänger
t
TKDP-SS01-6-17
Eigenschaften von Mobile IP mit Reverse
Tunneling
1. MN sendet an FA (kann gekapselt sein)
2. FA tunnelt Paket an HA
durch Kapselung
3. HA leitet das Paket normal an
Empfänger weiter
TKDP-SS01-6-18
Mobile IP und IPv6
Router akzeptieren oft nur „topologisch korrekte“ Adressen
ein durch den FA gekapseltes Paket des MN ist nun topologisch
korrekt
weiterhin Multicast und TTL-Problematik nun gelöst
(TTL im Heimatnetz richtig, nun aber u.U. zu weit vom Ziel)
Reverse Tunneling löst nicht
Problematik der firewalls, hier könnte dann der umgekehrte Tunnel
zur Umgehung der Schutzmechnismen missbraucht werden (tunnel
hijacking)
Optimierung der Wege, d.h. Pakete werden normalerweise über
den Tunnel zum HA geleitet, falls Tunneln nicht ausgeschaltet ist
(u.U. doppeltes Triangular-Routing)
Der neue Standard ist rückwärtskompatibel
Erweiterungen können einfach integriert werden und kooperieren
mit Implementierungen ohne die Erweiterung
TKDP-SS01-6-19
Mobile IP für IPv4 entwickelt, IPv6 erleichtert aber vieles
Sicherheit ist integriert und nicht aufgesetzt, Authentifikation aller
Aktionen wurde von vornherein bedacht
COA kann über Autokonfiguration erhalten werden
(DHCPv6 wäre ein mögliches Protokoll hierfür)
FA wird nicht mehr benötigt, da nun alle Router das sog. Router
Advertisement beherrschen, dieses kann nun an Stelle des
speziellen Agent Advertisement eingesetzt werden
MN kann automatisch Sender über COA benachrichtigen, senden
via HA entfällt dann (automatische Wegoptimierung)
„sanfte“ Wechsel, d.h. ohne Paketverluste, zwischen verschiedenen
Subnetzen werden unterstützt
• MN sendet dazu seinem vorherigen Router die neue COA
• der alte Router kapselt nun automatisch alle noch eingehenden
Pakete für MN und leitet sie zur neuen COA weiter
• die Authentizität bleibt dabei stets gewährleistet
TKDP-SS01-6-20
Einige Probleme mit Mobile IP
Sicherheit in Mobile IP
Sicherheit
Authentifikation mit FA problematisch, da u.U. nicht unter eigener
Kontrolle (fremde Organisation)
kein Protokoll für die Schlüsselverwaltung und -verteilung im
Internet standardisiert
Patent- und Exportproblematik
Firewalls
verhindern typischerweise den Einsatz von Mobile IP, spezielle
Konfigurationen sind nötig (z.B. reverse tunneling)
QoS
häufige erneute Reservierungen im Fall von RSVP
Tunneln verhindert das Erkennen eines gesondert zu behandelten
Datenstroms
Sicherheit, Firewalls, QoS etc. sind aktueller Gegenstand vieler
Arbeiten und Diskussionen!
Sicherheitsanforderungen
(Security Architecture for the Internet Protocol, RFC 1825)
Integrität (Integrity)
Daten können auf dem Weg vom Sender zum Empfänger nicht
verändert werden, ohne dass der Empfänger es bemerkt
Authentizität (Authentication)
Absender = Sender und empfangene = gesendete Daten
Vertraulichkeit (Confidentiality)
Nur Sender und Empfänger können die Daten lesen
Nicht-Zurückweisbarkeit (Non-Repudiation)
Sender von Daten kann nicht abstreiten, diese gesendet zu haben
Verkehrsflussanalyse (Traffic Analysis)
Erstellung von Bewegungsprofilen sollte nicht möglich sein
Wiedereinspielsicherung (Replay Protection)
Abgefangene gültige Registrierung, die erneut gesendet wird, wird
als ungültig erkannt
TKDP-SS01-6-21
Sicherheitsarchitektur bei IP
Sicherheitsarchitektur bei Mobile IP
Zwischen zwei oder mehreren kommunizierenden Partnern muss die
Verwendung von Sicherheitsmechanismen abgestimmt werden. Alle Partner
müssen die gleichen Verfahren und Parameter verwenden (Security
Association).
Für die Sicherung von IP-Nachrichten werden zwei Header definiert:
Authentication-Header
• Sichert die Integrität und die Authentizität von IP-Datagrammen
• Bei Verwendung von asymmetrischen Verschlüsselungsverfahren
wird auch die Nicht-Zurückweisbarkeit erfüllt
IP-Header
Authentification-Header
Authentication-Header
unverschlüsselter Teil
UDP/TCP-Paket
UDP/TCP-Packet
verschlüsselter Teil
ESP-Header
Für die Sicherung von Registrierungen wurde eine „Mobile Security
Association“ definiert, in der die Vereinbarungen zwischen dem
mobilen Knoten, dem Heimatagenten und dem Fremdagenten getroffen
werden.
Erweiterungen der IP-Sicherheitsarchitektur
Authentication-Erweiterung der Registrierung
MH-FA-Auth.
FA-HA-Auth.
MH-HA-Authentication
Registration Request
MH
Encapsulation Security Payload
• Schützt die Vertraulichkeit zwischen zwei Kommunikationspartnern
IP-Header
TKDP-SS01-6-22
verschlüsselte Daten
TKDP-SS01-6-23
Registration Reply
Registration Request
FA
Registration Reply
HA
Verhindern des wiederholten Rücksendens von Registrierungen
• Zeitstempel: 32 bit Zeitstempel + 32 bit Zufallszahl
• Einmalwerte („nonces“):
32 bit Zufallszahl (MH) + 32 bit Zufallszahl (HA)
TKDP-SS01-6-24
Schlüsselvergabe durch den Heimatagenten
Mobile IP braucht eine Infrastruktur
Home Agent/Foreign Agent im Festnetz
DNS, Routing etc. nicht für Mobilität ausgelegt
Oft keine Infrastruktur vorhanden
abgelegene Gegenden, spontane Treffen, Katastrophen
auch Kosten können gegen eine Infrastruktur sprechen!
Hauptproblem: Wegwahl
keine Standard-Router vorhanden
potentiell muß jeder Knoten weiterleiten können
Der Heimatagent dient als „Schlüsselverteilzentrale“
FA
MH
Antwort:
EHA-FA {Sitzungsschlüssel}
EHA-MH {Sitzungsschlüssel}
HA
Ad hoc-Netzwerke
Fremdagent unterhält Security Association mit Heimatagent
Mobiler Knoten registriert eine neue Bindung mit dem
Heimatagenten
Heimatagent antwortet mit neuem Sitzungsschlüssel für
Fremdagent und mobilem Knoten
A
B
C
TKDP-SS01-6-25
Routing-Beispiel für ein ad-hoc-Netzwerk
N1
Zeit = t1
N5
N3
N2
N3
N4
Traditionelle Routing-Algorithmen
N1
N2
N4
TKDP-SS01-6-26
N5
Zeit = t2
gute Verbindung
schlechte Verbindung
TKDP-SS01-6-27
Distance Vector
periodischer Austausch mit den physikalischen Nachbarn wer über
welche Distanz erreicht werden kann
Auswahl des kürzesten Pfades bei Wegalternativen
Link State
periodische Benachrichtigung aller Router über den Zustand aller
physikalischen Verbindungen
Router erhalten also ein „vollständiges“ Bild des Netzes
Beispiel
ARPA Packet Radio Network (1973), Einsatz von DV-Routing
alle 7,5s Austausch der Routing-Tabelle mit Verbindungsqualität
Aktualisierung der Tabellen auch durch Empfang von Paketen
Routing-Probleme wurden versucht mit begrenztem Fluten zu
lösen
TKDP-SS01-6-28
Probleme traditioneller Routing-Algorithmen
Dynamik der Topologie
häufige Änderung der Verbindungen, Teilnehmer,
Verbindungsqualitäten systeminhärent
Begrenzte Leistung der mobilen Geräte
periodische Aktualisierungen der Routing-Tabellen benötigt viel
Energie ohne Nutzdaten zu senden, Ruhemodus unmöglich
ohnehin begrenzte Bandbreite der Geräte zusätzlich durch
Austausch der Routing-Information geschmälert
Verbindungen können asymmetrisch sein, d.h. richtungsabhängige
Übertragungsqualitäten besitzen
DSDV (Destination Sequenced Distance Vector)
Erweiterung des Distance Vector Routing
Sequenznummer für jede Routenaktualisierung
Sicherstellung, dass Aktualisierungen in der richtigen Reihenfolge
ausgeführt werden
vermeidet dadurch Schleifen und Inkonsistenzen
Dämpfung der Änderungen
Speichern der Zeitdauer zwischen erster und bester Ankündigung
eines Weges
Zurückhalten einer Aktualisierung, wenn sie vermutlich nicht stabil
ist (basierend auf der gespeicherten Zeit)
Problem
Protokolle wurden für Festnetze mit relativ seltenen Änderungen
entworfen und gehen meist von symmetrischen Verbindungen aus
TKDP-SS01-6-29
Dynamic Source Routing I
TKDP-SS01-6-30
Dynamic Source Routing II
Trennung der Routing-Aufgabe in Auffinden und Aufrechterhalten
Auffinden eines Weges
Aussenden eines Broadcast-Pakets mit Zieladresse und Kennung
bei Empfang eines Broadcast-Pakets
• falls Empfänger, dann Rücksendung an Absender
• falls Paket bereits früher erhalten (Kennung), verwerfen
• sonst eigene Adresse anhängen und als Broadcast weiterleiten
Sender erhält Paket mit aktuellem Weg (Adressliste) zurück
Auffinden eines Weges
nur wenn wirklich ein Weg zum Senden von Daten zu einem
bestimmten Ziel benötigt wird und noch keiner vorhanden ist
Aufrechterhaltung eines Weges
nur während ein Weg aktuell benutzt wird, muss dafür gesorgt
werden, dass er weiterhin funktioniert
Optimierungen
Begrenzung durch maximale „Ausdehnung“ des mobilen Netzes
(falls bekannt)
Caching von Weginformationen mit Hilfe von vorbeikommenden
Paketen
• kann dann für eigene oder fremde Wegwahl ausgenutzt
werden
Keine periodischen Aktualisierungen notwendig!
TKDP-SS01-6-31
TKDP-SS01-6-32
Dynamic Source Routing III
Clustering von ad-hoc-Netzwerken
Aufrechterhaltung eines Weges
nach dem Senden
• Warten auf die Quittung auf Schicht 2 (falls vorhanden)
• Mithören im Medium, ob Paket weitergeleitet wird (falls
möglich)
• Anforderung einer expliziten Bestätigung
falls Probleme erkannt werden, kann der Sender informiert oder
lokal ein neuer Weg gesucht werden
Basisstation
Internet
Gruppenzugang
Gruppe
Supergruppe
TKDP-SS01-6-33
Interferenz-basiertes Routing
Beispiele für Interferenz-basiertes Routing
Wegwahlentscheidung basiert auf Annahmen über Interferenzen
N1
N2
E1
S1
N3
N4
S2
N5
N7
Nachbarn
(d.h. in Funkreichweite)
N6
N8
TKDP-SS01-6-34
E2
Least Interference Routing (LIR)
Bestimmung der Kosten eines Weges basierend auf der Anzahl von
Empfängern, die eine Sendung hören könnten
Max-Min Residual Capacity Routing (MMRCR)
Bestimmung der Kosten eines Weges basierend auf einer
Wahrscheinlichkeitsfunktion von erfolgreichen Übertragungen und
Interferenzen
Least Resistance Routing (LRR)
Bestimmung der Kosten eines Weges basierend auf Interferenz,
zusammengesetzt aus Informationen über Störung, Jamming und
anderen Übertragungen
LIR relativ einfach zu implementieren, da nur Informationen über die
direkten Nachbarn benötigt werden
N9
TKDP-SS01-6-35
TKDP-SS01-6-36
Motivation für die Änderung von
Transportprotokollen
Motivation II
Transportprotokolle bisher entworfen für
Stationäre Endgeräte
Festnetze
Forschungsschwerpunkte
Leistungsfähigkeit
Staukontrolle
Effiziente Übertragungswiederholung
TCP Staukontrolle
in Festnetzen entstehen Paketverluste i.Allg. durch eine Überlast
Router müssen Pakete verwerfen, sobald ihre Puffer voll sind
TCP bemerkt Stau nur indirekt anhand von ausbleibenden
Quittungen, Übertragungswiederholungen würden nun den Stau
nur noch verschlimmern
Slow-Start Algorithmus
TCP Slow-Start Algorithmus
Sender berechnet ein Staufenster für einen Empfänger
Start mit Fenstergröße gleich 1 Segment
exponentielles Wachstum des Fensters bis zu einem Schwellwert,
dann linear
bleibt eine Bestätigung aus, so wird der aktuelle Schwellwert
halbiert, das Staufenster beginnt wieder mit einem Segment
TCP Fast Retransmit/Fast Recovery
TCP sendet Bestätigungen nur nach Empfang eines Pakets
gehen mehrere Bestätigungen für das gleiche Paket ein, so bedeutet
dies, dass eine Lücke aufgetreten ist, jedoch alle Pakete bis zur
Lücke empfangen wurden und weitere Pakete aktuell empfangen
werden
der Paketverlust ist also nicht auf einen Stau zurückzuführen,
Slow-Start wird nicht eingesetzt, sondern sofort mit dem aktuellen
Fenster weitergesendet
TKDP-SS01-6-37
Auswirkung der Mobilität auf TCP-Mechanismen
TCP geht bei Paketverlust von Stau aus
dies ist meist falsch in drahtlosen Netzen, hier herrschen
Paketverluste durch Übertragungsfehler vor
weiterhin kann die Mobilität zu Paketverlusten führen, wenn ein
mobiler Knoten von einem Zugangspunkt (Foreign Agent) zu
einem anderen geht und Pakete noch zum falschen Zugangspunkt
unterwegs sind
Die Leistung eines unveränderten TCP bricht katastrophal ein!
TCP kann aber nicht „grundsätzlich“ verändert werden, da
Interoperabilität mit Festnetzrechnern notwendig
TCP-Mechanismen halten im Festnetz das Internet zusammen
TKDP-SS01-6-38
Indirektes TCP I
Indirektes TCP, auch I-TCP, segmentiert die Verbindung
keine Änderung am TCP-Protokoll für Rechner im Festnetz, hier
ist die installierte Basis zu hoch
optimiertes TCP-Protokoll für Mobilrechner
Auftrennung der TCP-Verbindung z.B. am Foreign Agent in 2
TCP-Verbindungen, keine „echte“ Ende-zu-Ende-Semantik mehr
Rechner im Festnetz bemerken nichts vom mobilen Teil
Mobiles Endgerät
(mobile host)
Zugangspunkt
(foreign agent)
„drahtloses“ TCP
TKDP-SS01-6-39
„festes“ Internet
normales TCP
TKDP-SS01-6-40
I-TCP Zustandsübertragung
Indirektes TCP II
Vorteile
keine Änderungen im Festnetzbereich, alle
Optimierungsmaßnahmen helfen hier weiterhin
Fehler auf der drahtlosen Strecke pflanzen sich nicht ins Festnetz
fort
relativ einfach beherrschbar, da mobile TCP-Varianten nur die
kurze Strecke (ein „hop“) zwischen Foreign Agent und
Mobilrechner betreffen
dadurch sehr schnelle Übertragungswiederholung, da
Verzögerungszeit auf der Mobilstrecke bekannt ist
Zugangspunkt1
Übertragung von socket
und Zustand (cache)
Internet
Nachteile
Verlust der TCP-Semantik, ACK an Sender heißt nun nicht mehr,
dass der Empfänger wirklich die Daten erhalten hat - was passiert,
wenn der Foreign Agent abstürzt? Konsistenz der Sichten?
vergrößerte Latenzzeiten durch Pufferung der Daten im Foreign
Agent und evtl. Übertragung an den neuen Foreign Agent
Zugangspunkt2
mobiler Knoten
TKDP-SS01-6-41
Snooping TCP I
TKDP-SS01-6-42
Snooping TCP II
„Transparente“ Erweiterung von TCP im Foreign Agent
Puffern der zum Mobilrechner gesendeten Daten
bei Datenverlust auf der Mobilstrecke (beide Richtungen) direkte
Übertragungswiederholung zwischen Foreign Agent und
Mobilrechner („lokale“ Übertragungswiederholung)
dazu hört der Foreign Agent den Datenverkehr ab und erkennt
Bestätigungen in beide Richtungen (Filtern der ACKs)
TCP muss nur im Foreign Agent erweitert werden
Datentransfer zum Mobilrechner
FA puffert die Daten bis zum ACK des MN, erkennt Paketverluste
durch duplizierte ACKs oder time-out
schnelle Übertragungswiederholung, unbemerkt vom Festnetz
Datentransfer vom Mobilrechner
FA erkennt Paketverluste auf dem Weg vom MN anhand der
Sequenznummern, sendet daraufhin NACK zum MN
MN kann nun sehr schnell erneut übertragen
Integration der MAC-Schicht
MAC-Schicht hat oft ähnliche Mechanismen wie TCP
schon in der MAC-Schicht können evtl. Paketduplikate durch
Übertragungswiederholungen erkannt und verworfen werden
Lokale Übertragungswiederholung
„festes“ Internet
Probleme
Snooping TCP isoliert die drahtlose Verbindung nicht so gut
je nach Verschlüsselungsverfahren ist snooping nutzlos
Puffern der Daten
Ende-zu-Ende-TCP-Verbindung
TKDP-SS01-6-43
TKDP-SS01-6-44
Mobile TCP
Fast Retransmit/Fast Recovery
Spezielle Handhabung längerer und/oder häufiger Unterbrechungen
M-TCP teilt die Verbindung ähnlich wie I-TCP auf
normales TCP im Festnetz bis zum Supervisory Host (SH)
optimiertes TCP zwischen SH und MH
Supervisory Host
keine Pufferung der Daten, keine Übertragungswiederholung
Überwachung aller Pakete, sobald eine Unterbrechung festgestellt wird:
• setze Sendefenster auf 0
• der Sender wechselt dann automatisch in den Persistent Mode
der alte oder neue SH öffnet das Fenster wieder
Vorteile
erhält Semantik, unterstützt Unterbrechungen, keine Zustandsübertragung
notwendig bei Wechsel des Zugangspunktes
Nachteile
Verluste auf der drahtlosen Strecke wirken sich auf das Festnetz aus
verwendet spezielles TCP auf der drahtlosen Strecke
Wechseln des Foreign Agent bedeutet meist Paketverlust
TCP reagiert mit Slow-Start obwohl kein Stau vorliegt
Erzwingen des Fast Retransmit
sobald sich der Mobilrechner bei einem neuen Foreign Agent
registriert hat, sendet er bewusst duplizierte Bestätigungspakete aus
damit erzwingt der Mobilrechner bei den entsprechenden Partnern
im Festnetz den Fast Retransmit-Modus
ebenso wird das TCP auf dem Mobilrechner „gezwungen“
weiterhin schnell zu senden, sobald die neue Registrierung
abgeschlossen ist
Vorteil
einfache Änderungen erzielen große Leistungssteigerung
Nachteil
weitere Vermischung von IP und TCP, Transparenz des Verfahrens
problematisch
TKDP-SS01-6-45
Transmission/Timeout Freezing
TKDP-SS01-6-46
Selektive Übertragungswiederholung
Mobilrechner können auch relativ lange abgekoppelt sein
keinerlei Datenaustausch möglich in z.B. Tunnel,
Verbindungstrennung bei Überlast
TCP bricht daraufhin die Verbindung komplett ab
TCP-Quittungen sind normalerweise kumulativ
ACK n bestätigt korrekten und reihefolgerichtigen Empfang bis n
treten nun einzelne Lücken im Datenstrom auf, so werden oft
unnötigerweise Pakete erneut übertragen
„Einfrieren“ von TCP
die MAC-Schicht kann oft erkennen, dass ein Verbindungsabbruch
bevorsteht
Signalisierung von TCP über dieses bevorstehende Ereignis
TCP versucht nun, nicht weiter zu senden, und nimmt auch keinen
Stau an
erneute Signalisierung bei Wiederaufnahme des Kontakts
Vorteil
Schema unabhängig von Verschlüsselung, Dateninhalten
Lösung durch selektive Übertragungswiederholung
RFC2018 erlaubt Quittung aller empfangenen Pakete, nicht nur der
reihefolgetreuen und lückenlosen
Vorteil
weitaus effizienter
wird schon häufig im Festnetz genutzt
Nachteil
etwas komplexere Empfängersoftware, mehr Speicher benötigt
Nachteil
Änderung von TCP auf dem MH, MAC-abhängig
TKDP-SS01-6-47
TKDP-SS01-6-48
Transaktionsorientiertes TCP
Vergleich der vorgestellten Verfahren
TCP-Phasen
Verbindungsaufbau, Datenübertragung, Verbindungsabbau
Aufbau und Abbau nach 3-Wege-Handshake benötigen je 3 Pakete
selbst für kurze Nachrichten werden so min. 7 Pakete benötigt!
Transaktionsorientiertes TCP
RFC1644, T-TCP, beschreibt eine TCP-Version, die dies
vermeidet
Verbindungsaufbau-, Daten-, und Verbindungsabbaupakete
werden zusammengefasst
dadurch kann mit 2 oder 3 Paketen ausgekommen werden
Vorteil
Effizienz
Nachteil
geänderte TCP-Version
Mobilität nicht mehr transparent
TKDP-SS01-6-49
Verfahren
Indirektes TCP
Mechanismus
Auftrennen in zwei TCPVerbindungen
Snooping TCP
Mithören von Daten und
Quittungen, lokale
Wiederholung
M-TCP
Auftrennen in zwei TCPVerbindungen, Drosseln
des Senders über die
Sendefenstergröße
Fast Retransmit/
Vermeidung von
Fast Recovery
slow-start nach
Verbindungswechsel
Transmission/
Einfrieren des TCPTimeout Freezing Zustands bei
Unterbrechung
Selektive Übertra- Wiederholung nur der
gungswiederecht verlorengeholung
gangenen Daten
TransaktionsZusammenfassung von
orientiertes TCP
Verbindungsauf/-abbau
und Datenpaketen
Vorteile
Nachteile
Isolation der drahtlosen
Strecke, einfach
Transparent für Ende-zuEnde, Integration von
MAC
Erhalt der Ende-zu-Ende
Semantik, kommt mit
langen/häufigen
Unterbrechungen klar
Einfach, effizient
Verlust der TCPSemantik, erhöhte Latenz
Problematisch bei
Verschlüsselung,
schlechtere Isolation
Schlechte Isolation,
höherer Berechnungsaufwand durch
Bandbreitenmanagement
Vermischung der
Schichten, nicht
Transparent
Änderung von TCP,
MAC-abhängig
Unabhängig von
Dateninhalten,
Verschlüsselung
Sehr effizient
Effizient
Etwas komplexere
Empfängersoftware, mehr
Speicher
Geändertes TCP, nicht
mehr transparent
TKDP-SS01-6-50