Zum Hauptinhalt springen

9.1.1. Optionen mit eingeschränkter und voller Funktionalität (Limited and Full-Functionality Options)

Dieser Abschnitt erläutert die zwei Modi für ECN in IP-Tunneln.

9.1.1.1. Limited-Functionality Option​

Definition​

Der Tunnel-Eintrittsknoten setzt immer Not-ECT im äußeren Header, unabhängig vom inneren Header.

Verhalten​

Bei Encapsulation:

Für alle Pakete:
    Äußeres_ECN = Not-ECT (00)
    Inneres_ECN = unverändert

Bei Decapsulation:

Resultierendes_ECN = Inneres_ECN (einfach äußeren Header entfernen)

Vorteile​

  • Einfachheit: Keine komplexe Logik erforderlich
  • Kompatibilität: Funktioniert mit allen Netzwerken
  • Keine Konfiguration: Keine Verhandlung zwischen Tunnel-Endpunkten nötig

Nachteile​

  • Kein ECN im Tunnel: Pakete im Tunnel nutzen kein ECN
  • Paketverlust: Überlastung im Tunnel führt zu Paketverlust, nicht CE-Markierung
  • Suboptimale Leistung: Verliert ECN-Vorteile innerhalb des Tunnels

9.1.1.2. Full-Functionality Option​

Definition​

Der Tunnel verwendet ECN im äußeren Header, wenn das innere Paket ECN-fähig ist.

Verhalten​

Bei Encapsulation:

Wenn Inneres_ECN == Not-ECT:
    Äußeres_ECN = Not-ECT
Sonst (Inneres ist ECT(0), ECT(1), oder CE):
    Äußeres_ECN = ECT(0) oder ECT(1)
    # CE wird nicht in äußerem gesetzt

Bei Decapsulation:

Wenn (Äußeres_ECN == CE) UND (Inneres_ECN ist ECT):
    Resultierendes_ECN = CE
Sonst wenn (Äußeres_ECN == CE) UND (Inneres_ECN == Not-ECT):
    Paket verwerfen # Fehlersituation
Sonst:
    Resultierendes_ECN = Inneres_ECN

Vorteile​

  • Vollständige ECN-Nutzung: Überlastung im Tunnel wird durch CE signalisiert
  • Bessere Leistung: Weniger Paketverlust im Tunnel
  • Ende-zu-Ende-ECN: Vollständige ECN-Information vom Quell- zum Zielknoten

Nachteile​

  • Komplexität: Erfordert korrekte Encap/Decap-Logik
  • Verhandlung: Beide Tunnel-Endpunkte müssen Full-Functionality unterstützen
  • Potentielle Inkompatibilität: Kann mit einigen Middleboxen Probleme haben

9.1.1.3. Wahl zwischen Optionen​

Verwendung von Limited-Functionality WENN:​

  • Tunnel-Endpunkte können sich nicht koordinieren
  • Einer der Endpunkte unterstützt Full-Functionality nicht
  • Netzwerk zwischen Endpunkten hat bekannte ECN-Probleme
  • Einfachheit ist wichtiger als Leistung

Verwendung von Full-Functionality WENN:​

  • Beide Endpunkte unterstützen es
  • Tunnel-Endpunkte können sich koordinieren
  • Maximale Leistung gewünscht ist
  • Netzwerk ist ECN-freundlich

9.1.1.4. Dynamische Auswahl​

Implementierungen KÖNNEN:

  • Mit Full-Functionality beginnen
  • Bei Problemen auf Limited-Functionality zurückfallen
  • Pro-Tunnel-Konfiguration erlauben

9.1.1.5. Verhandlung zwischen Tunnel-Endpunkten​

Für Full-Functionality SOLLTEN Tunnel-Endpunkte:

  • Ihre ECN-Fähigkeit signalisieren
  • Gegenseitige Unterstützung bestätigen
  • Einigen sich auf Verwendung von Full-Functionality

Für IPsec-Tunnel: Siehe Abschnitt 9.2.1 für spezifische Verhandlungsmechanismen.

Für manuelle Tunnel: Konfiguration kann statisch sein.

9.1.1.6. Empfehlung​

Neue Implementierungen SOLLTEN:

  • Full-Functionality implementieren
  • Limited-Functionality als Fallback bereitstellen
  • Einfache Konfiguration zwischen Modi erlauben

Bestehende Tunnel KÖNNEN:

  • Limited-Functionality verwenden (akzeptabel)
  • Auf Full-Functionality aufrüsten wenn möglich
Letztes Update am