5. Datagramm-Paketisierungsschicht PMTUD

Dieser Abschnitt spezifiziert Datagramm-PLPMTUD (DPLPMTUD). Die Methode kann an verschiedenen Punkten im IP-Protokollstapel eingeführt werden, um die PLPMTU zu ermitteln, sodass eine Anwendung eine geeignete MPS für den aktuellen Netzwerkpfad nutzen kann.

DPLPMTUD SOLLTE nur auf einer Schicht zwischen einem Paar von Endpunkten durchgeführt werden. Daher sollten eine obere Schicht PL oder Anwendung DPLPMTUD vermeiden, wenn DPLPMTUD auf einer unteren Schicht aktiviert ist. Ein PL MUSS die von DPLPMTUD angegebene MPS anpassen, um jeden zusätzlichen Overhead zu berücksichtigen, der durch den PL eingeführt wird.

Beispiele für DPLPMTUD-Implementierungsorte

Application Data  *
   ↓
QUIC/RTP         * (Kann DPLPMTUD implementieren)
   ↓
UDP              * (Kann DPLPMTUD implementieren)
   ↓
IP Layer
   ↓
Network Interface

Die zentrale Idee von DPLPMTUD ist das Sondieren durch den Sender. Sondierungspakete werden gesendet, um die maximale Größe der Benutzernachricht zu finden, die vollständig vom Sender zum Ziel übertragen werden kann.

Die folgenden Abschnitte identifizieren die für die Implementierung erforderlichen Komponenten, bieten einen Überblick über die Betriebsphasen und spezifizieren die Zustandsmaschine und den Suchalgorithmus.

5.1. DPLPMTUD-Komponenten

Dieser Abschnitt beschreibt die Timer, Konstanten und Variablen von DPLPMTUD.

5.1.1. Timer

Die Methode nutzt bis zu drei Timer:

PROBE_TIMER

• Konfiguration: Timeout größer als die maximale Zeit zum Empfang einer Bestätigung eines Sondierungspakets
• Minimum: DARF NICHT weniger als 1 Sekunde sein
• Empfohlen: SOLLTE größer als 15 Sekunden sein
• Referenz: Abschnitt 3.1.1 der UDP-Verwendungsrichtlinien [BCP145] bietet Anleitung zur Auswahl von Timerwerten

PMTU_RAISE_TIMER

• Funktion: Der Zeitraum, den ein Sender weiterhin die aktuelle PLPMTU verwenden wird, danach tritt er erneut in die Suchphase ein
• Zeitraum: 600 Sekunden, wie von PLPMTUD [RFC4821] empfohlen
• Optimierung: DPLPMTUD KANN das Senden von Sondierungspaketen unterdrücken, wenn keine Anwendungsdaten seit dem letzten Sondierungspaket gesendet wurden. Ein PL, der die neueste PMTU beim erneuten Senden von Benutzerdaten bevorzugt, kann wählen, die PMTU-Erkennung für jeden Pfad fortzusetzen. Dies führt jedoch zum Senden zusätzlicher Pakete

CONFIRMATION_TIMER

• Anwendbarkeit: DARF NICHT verwendet werden, wenn ein bestätigter PL verwendet wird
• Funktion: Für andere PLs, konfiguriert als der Zeitraum, den ein PL-Sender wartet, bevor er bestätigt, dass die aktuelle PLPMTU noch unterstützt wird
• Beziehung: Kleiner als PMTU_RAISE_TIMER, verwendet zur Reduzierung der PLPMTU (z.B. wenn ein schwarzes Loch auftritt)
• Häufigkeit: Die Bestätigung muss häufig genug sein, damit der sendende PL keine große Menge an Verkehr in ein schwarzes Loch leitet, wenn Daten fließen
• Referenz: Abschnitt 3.1.1 der UDP-Verwendungsrichtlinien [BCP145] bietet Anleitung zur Auswahl von Timerwerten
• Optimierung: DPLPMTUD KANN das Senden von Sondierungspaketen unterdrücken, wenn keine Anwendungsdaten seit dem letzten Sondierungspaket gesendet wurden

Hinweis: DPLPMTUD spezifiziert verschiedene Timer; eine Implementierung kann jedoch wählen, diese Timerfunktionen mit einem einzigen Timer zu realisieren.

5.1.2. Konstanten

Die folgenden Konstanten sind definiert:

MAX_PROBES

• Definition: Der maximale Wert des PROBE_COUNT-Zählers
• Bedeutung: Stellt eine Grenze für die Anzahl aufeinanderfolgender Sondierungsversuche jeglicher Größe dar
• Vorteil: Ein MAX_PROBES-Wert größer als 1 kann Robustheit gegen isolierten Paketverlust bieten
• Standard: 3

MIN_PLPMTU

• Definition: Die kleinste PLPMTU-Größe, die DPLPMTUD zu verwenden versuchen wird
• Konfiguration: Ein Endpunkt muss möglicherweise MIN_PLPMTU konfigurieren, um Platz für Erweiterungsheader und andere Kapselung auf Schichten unterhalb des PL bereitzustellen
• Pfadabhängigkeit: Dieser Wert kann schnittstellen- und pfadabhängig sein
• IPv6: Diese Größe ist größer oder gleich der Größe auf der PL, die zu einem 1280-Byte-IPv6-Paket führt, wie in [RFC8200] spezifiziert
• IPv4: Diese Größe ist größer oder gleich der Größe auf der PL, die zu einem 68-Byte-IPv4-Paket führt
  • Hinweis: IPv4-Router sind verpflichtet, ein Datagramm von 68 Bytes ohne weitere Fragmentierung weiterleiten zu können. Dies ist die kombinierte Größe eines IPv4-Headers und der minimalen Fragmentgröße von 8 Bytes. Darüber hinaus sind Empfänger verpflichtet, fragmentierte Datagramme von mindestens 576 Bytes Größe wieder zusammensetzen zu können, wie in Abschnitt 3.3.3 von [RFC1122] angegeben

MAX_PLPMTU

• Definition: Die größte PLPMTU-Größe
• Einschränkung: Muss kleiner oder gleich der maximalen Größe des PL-Pakets sein, das auf der ausgehenden Schnittstelle gesendet werden kann (eingeschränkt durch die lokale Schnittstellen-MTU)
• Überlegung: Sollte auch kleiner sein als die maximale Größe des PL-Pakets, das der entfernte Endpunkt empfangen kann (eingeschränkt durch EMTU_R), wenn dies bekannt ist
• Designeinschränkung: Kann durch das Design oder die Konfiguration des verwendeten PL eingeschränkt sein
• Anwendungseinschränkung: Eine Anwendung oder ein PL KANN eine kleinere MAX_PLPMTU wählen, wenn es nicht notwendig ist, Pakete größer als eine bestimmte Größe zu senden

BASE_PLPMTU

• Definition: Eine konfigurierte Größe, die voraussichtlich für die meisten Pfade funktioniert
• Bereich: Gleich oder größer als MIN_PLPMTU und kleiner als MAX_PLPMTU
• Empfohlen: Für die meisten PLs wird eine geeignete BASE_PLPMTU größer als 1200 Bytes sein
• IPv4: Bei Verwendung von IPv4 gibt es keine derzeit spezifizierte äquivalente Größe, eine EMPFOHLENE Standard-BASE_PLPMTU von 1200 Bytes

5.1.3. Variablen

Diese Methode nutzt eine Reihe von Variablen:

PROBED_SIZE

• Definition: Die Größe des aktuellen Sondierungspakets, wie auf der PL bestimmt
• Natur: Dies ist ein vorläufiger Wert für die PLPMTU, der auf Bestätigung wartet

PROBE_COUNT

• Definition: Eine Zählung der Anzahl aufeinanderfolgender erfolgloser Sondierungspakete, die gesendet wurden
• Zurücksetzen: Dies wird auf Null gesetzt, jedes Mal wenn ein Sondierungspaket bestätigt wird
• Hinweis: Ein gewisser Verlust von Sondierungen wird während einer Suche erwartet, daher ist der Verlust einer einzelnen Sondierung keine Anzeige für ein PMTU-Problem

Paketgrößen-Beziehungsdiagramm

MAX_PLPMTU ────────┐
                   │
                   ↓
PROBED_SIZE ───────┤ (Wird sondiert)
                   │
                   ↓
PLPMTU ────────────┤ (Aktuell verwendet)
                   │
                   ↓
BASE_PLPMTU ───────┤ (Basislinie)
                   │
                   ↓
MIN_PLPMTU ────────┘ (Minimum)

Das obige Diagramm veranschaulicht die Beziehung zwischen den Paketgrößenkonstanten und -variablen, wenn der DPLPMTUD-Algorithmus Pfadsondierung durchführt, um die PLPMTU-Größe zu erhöhen. Sondierungspakete der Größe PROBED_SIZE wurden gesendet. Sobald sie bestätigt sind, wird die PLPMTU auf PROBED_SIZE angehoben, wodurch der DPLPMTUD-Algorithmus PROBED_SIZE weiter erhöhen kann und sich dem Senden von Sondierungspaketen der tatsächlichen PMTU-Größe nähert.

5.1.4. Überblick über DPLPMTUD-Phasen

Dieser Abschnitt bietet eine informative Übersicht auf hoher Ebene über die DPLPMTUD-Methode, indem er die Bewegung der Methode durch mehrere Betriebsphasen beschreibt. Weitere Details finden sich in der Zustandsmaschine (Abschnitt 5.2).

DPLPMTUD-Phasenflussdiagramm

Initial → Basisphase → Suchphase → Suchabschlussphase
  ↓                                  ↑
  └──────→ Fehlerphase ←─────────────┘

Basisphase

• Zweck: Die Basisphase verwendet Pakete der Größe BASE_PLPMTU, um die Konnektivität zum entfernten Peer zu bestätigen
• Verbindungsbestätigung: Für einen verbindungsorientierten PL ist die Verbindungsbestätigung implizit (kann im PL-Verbindungshandshake durchgeführt werden). Ein verbindungsloser PL sendet Sondierungspakete und verwendet die Bestätigung dieses Sondierungspakets, um zu bestätigen, dass der entfernte Peer erreichbar ist
• PLPMTU-Bestätigung: Der Sender bestätigt auch, dass der Netzwerkpfad BASE_PLPMTU unterstützt. Dies kann durch Verwendung von PL-Mechanismen (z.B. unter Verwendung eines Handshake-Pakets der Größe BASE_PLPMTU) oder durch Senden eines Sondierungspakets der Größe BASE_PLPMTU und Bestätigung des Empfangs dieses Sondierungspakets erreicht werden
• Sondierungstiming: Ein Sondierungspaket der Größe BASE_PLPMTU kann unmittelbar nach Eintritt in die Basisphase gesendet werden (nach der Verbindungsprüfung). Ein PL, der keine Pfade mit einer PLPMTU kleiner als BASE_PLPMTU unterstützen möchte, kann diese Phase auf einen einzigen Schritt vereinfachen, indem er die Verbindungsprüfung mit einer Sondierung der Größe BASE_PLPMTU durchführt
• Erfolg: Nach Bestätigung tritt DPLPMTUD in die Suchphase ein
• Fehler: Wenn die Basisphase BASE_PLPMTU nicht bestätigen kann, tritt DPLPMTUD in die Fehlerphase ein

Suchphase

• Zweck: Die Suchphase nutzt einen Suchalgorithmus, um Sondierungspakete zu senden, um zu versuchen, die PLPMTU zu erhöhen
• Beendigung: Der Algorithmus endet durch Eintritt in die Suchabschlussphase, wenn eine geeignete PLPMTU gefunden wird
• PTB-Antwort: Der PL kann auf PTB-Nachrichten reagieren, indem er PTB-Nachrichten verwendet, um die Suche voranzubringen oder zu beenden, siehe Abschnitt 4.6

Suchabschlussphase

• Zustand: Die Suchabschlussphase wird betreten, wenn die PLPMTU auf einem Netzwerkpfad unterstützt wird
• Periodische Bestätigung: Der PL kann den CONFIRMATION_TIMER verwenden, um periodisch Sondierungspakete der aktuellen PLPMTU-Größe zu wiederholen
• Schwarzes-Loch-Erkennung: Wenn der Sender die Erreichbarkeit nicht bestätigen kann (z.B. wenn der CONFIRMATION_TIMER abläuft) oder der PL einen Mangel an Erreichbarkeit signalisiert, wird ein schwarzes Loch erkannt und DPLPMTUD tritt in die Basisphase ein
• Periodische Suche: Der PMTU_RAISE_TIMER wird verwendet, um periodisch die Suchphase wieder aufzunehmen, um zu ermitteln, ob die PLPMTU erhöht werden kann

Fehlerphase

• Auslöser: Die Fehlerphase wird betreten, wenn die PLPMTU-Informationen für einen Pfad widersprüchlich oder ungültig sind (z.B. BASE_PLPMTU nicht unterstützen können), was verhindert, dass DPLPMTUD fortfährt und die PLPMTU reduziert
• Minderung: Dieser Zustand implementiert eine Methode zur Minderung von Oszillationen in der Zustandsereignismaschine. Er signalisiert einen konservativen MPS-Wert an höhere Schichten über den PL
• Ausgang: Dieser Zustand wird verlassen, wenn Sondierungspakete keinen Fehler mehr erkennen. Der PL-Sender tritt dann in den Suchzustand ein

Robustheit: Eine Methode, die lediglich die PLPMTU auf eine geeignete Größe reduziert, ist ausreichend, um einen zuverlässigen Betrieb sicherzustellen, könnte aber sehr ineffizient sein, wenn sich die tatsächliche PMTU ändert oder wenn die Methode (aus welchem Grund auch immer) eine suboptimale Wahl für die PLPMTU trifft.

Vollständige Implementierung: Eine vollständige Implementierung von DPLPMTUD bietet einen Algorithmus, der es einem DPLPMTUD-Sender ermöglicht, die PLPMTU nach Änderungen der Pfadeigenschaften zu erhöhen, z.B. wenn ein Link mit einer größeren MTU neu konfiguriert wird oder wenn sich die Menge der von einem Ende-zu-Ende-Fluss durchquerten Links ändert (z.B. nach einer Routing- oder Pfad-Failover-Entscheidung).

5.2. Zustandsmaschine

Die Zustandsmaschine für DPLPMTUD ist unten dargestellt. Wenn Mehrpfad oder Multihoming unterstützt wird, ist für jeden Pfad eine Zustandsmaschine erforderlich.

Hinweis: Der Klarheit halber zeigt das Diagramm nicht alle Übergänge.

Zustandsmaschinendiagramm

        [DISABLED]
            ↓ ↑
      Verbindung hergestellt/Verloren
            ↓ ↑
         [BASE] ←──────────────┐
            ↓                   │
        Sondierungserfolg     Schwarzes-Loch-Erkennung
            ↓                   │
       [SEARCHING] ─────────────┤
            ↓                   │
      Sondierung abgeschlossen/Fehler │
            ↓                   │
    [SEARCH_COMPLETE] ──────────┘
            ↑ ↓
      Periodische Erhöhung/Schwarzes-Loch-Erkennung

        [ERROR]
      (Fehlerbehandlung)

Zustandsdefinitionen

DISABLED

• Anfangszustand: Der Anfangszustand vor Beginn der Sondierung
• Eingangsbedingung: Wird von jedem anderen Zustand betreten, wenn der PL einen Konnektivitätsverlust anzeigt
• Ausgangsbedingung: Verlassen dieses Zustands, sobald der PL Konnektivität zum entfernten PL anzeigt
• Übergang: Beim Übergang in den BASE-Zustand kann ein Sondierungspaket der Größe BASE_PLPMTU sofort gesendet werden

BASE

• Zweck: Wird verwendet, um zu bestätigen, dass der Netzwerkpfad die BASE_PLPMTU-Größe unterstützt, vorgesehen, um einer Anwendung zu ermöglichen, weiter zu funktionieren, wenn die tatsächliche PMTU vorübergehend reduziert wird. Er versucht auch zu vermeiden, dass ein Sender, der DPLPMTUD verwendet, nicht weiß, dass Pakete aufgrund eines Paket- oder ICMP-schwarzen Lochs über einen längeren Zeitraum nicht zugestellt werden, während er nach einer größeren PLPMTU sucht
• Bei Eintritt: PROBED_SIZE wird auf die BASE_PLPMTU-Größe gesetzt und PROBE_COUNT wird auf Null gesetzt
• Sondierung: Jedes Mal, wenn ein Sondierungspaket gesendet wird, wird der PROBE_TIMER gestartet
• Erfolgreicher Ausgang: Der Zustand wird verlassen, wenn ein Sondierungspaket bestätigt wird, der PL-Sender tritt in den SEARCHING-Zustand ein
• Fehlerausgang: Der Zustand wird auch verlassen, wenn PROBE_COUNT MAX_PROBES erreicht oder eine validierte PTB-Nachricht empfangen wird. Dies führt dazu, dass der PL-Sender in den ERROR-Zustand eintritt

SEARCHING

• Hauptzustand: Dies ist der Hauptsondierungszustand
• Eingangsbedingung: Wird betreten, wenn eine Sondierung von BASE_PLPMTU abgeschlossen ist
• Erfolgreiche Sondierung: Jedes Mal, wenn ein Sondierungspaket bestätigt wird, wird PROBE_COUNT auf Null gesetzt, PLPMTU wird auf PROBED_SIZE gesetzt, und PROBED_SIZE wird dann unter Verwendung des Suchalgorithmus erhöht (wie in Abschnitt 5.3 beschrieben)
• Sondierungsfehler: Wenn ein Sondierungspaket gesendet wird, ohne innerhalb der PROBE_TIMER-Periode bestätigt zu werden, wird PROBE_COUNT inkrementiert und eine neue Sondierung wird übertragen
• Ausgangsbedingung: Ausgang, wenn PROBE_COUNT MAX_PROBES erreicht, um SEARCH_COMPLETE zu betreten, eine validierte PTB empfangen wird, die der letzten erfolgreichen Sondierungsgröße entspricht (PL_PTB_SIZE = PLPMTU), oder eine Sondierung der Größe MAX_PLPMTU bestätigt wird (PLPMTU = MAX_PLPMTU)
• Schwarzes-Loch-Erkennung: Wenn ein schwarzes Loch erkannt wird, während man sich im SEARCHING-Zustand befindet, führt dies dazu, dass der PL-Sender in den BASE-Zustand eintritt

SEARCH_COMPLETE

• Abschlussflag: Zeigt an, dass die Suche abgeschlossen ist. Dies ist der normale Wartungszustand, in dem der PL nicht sondiert, um die PLPMTU zu aktualisieren
• Dauer: DPLPMTUD bleibt in diesem Zustand, bis entweder der PMTU_RAISE_TIMER abläuft oder ein schwarzes Loch erkannt wird
• Unbestätigter PL: Wenn DPLPMTUD einen unbestätigten PL verwendet und sich im SEARCH_COMPLETE-Zustand befindet, setzt der CONFIRMATION_TIMER periodisch PROBE_COUNT zurück und plant ein Sondierungspaket der Größe PLPMTU. Wenn MAX_PROBES aufeinanderfolgende Sondierungspakete der Größe PLPMTU nicht bestätigt werden, tritt die Methode in den BASE-Zustand ein
• Bestätigter PL: Bei Verwendung mit einem bestätigten PL (z.B. SCTP) SOLLTE DPLPMTUD in diesem Zustand keine PLPMTU-Sondierungen mehr generieren

ERROR

• Fehlersituation: Zeigt an, dass der Netzwerkpfad nicht bekanntermaßen eine PLPMTU von mindestens BASE_PLPMTU-Größe unterstützt oder dass es widersprüchliche Informationen über den Netzwerkpfad gibt, die andernfalls das MPS-Signal an höhere Schichten übermäßig oszillieren lassen könnten
• Oszillationsminderung: Dieser Zustand implementiert eine Methode zur Minderung von Oszillationen in der Zustandsereignismaschine
• Konservativer Wert: Er signalisiert einen konservativen MPS-Wert an höhere Schichten über den PL
• Ausgang: Dieser Zustand wird verlassen, wenn Sondierungspakete keinen Fehler mehr erkennen. Der PL-Sender tritt dann in den SEARCHING-Zustand ein
• Endpunkt-Fragmentierung: Die Implementierung erlaubt die Aktivierung der Endpunkt-Fragmentierung, wenn DPLPMTUD MIN_PLPMTU nicht innerhalb von PROBE_COUNT-Sondierungen validieren kann
• Deaktivieren: Wenn DPLPMTUD MIN_PLPMTU nicht validieren kann, wechseln Implementierungen in den DISABLED-Zustand
• Hinweis: MIN_PLPMTU kann mit BASE_PLPMTU identisch sein, was den Betrieb dieses Zustands vereinfacht

5.3. Suche zur Erhöhung der PLPMTU

Dieser Abschnitt beschreibt die von DPLPMTUD verwendeten Algorithmen, um nach einer größeren PLPMTU zu suchen.

5.3.1. Sondierung für eine größere PLPMTU

Implementierungen verwenden einen Suchalgorithmus über den Suchbereich, um zu bestimmen, ob der Netzwerkpfad eine größere PLPMTU unterstützen kann.

Die Methode ermittelt den Suchbereich, indem sie die minimale PLPMTU bestätigt und dann die Sondierung verwendet, um eine PROBED_SIZE kleiner oder gleich MAX_PLPMTU auszuwählen. Die MAX_PLPMTU ist das Minimum der lokalen MTU und EMTU_R (wenn vom entfernten Endpunkt gelernt). MAX_PLPMTU KANN durch eine Anwendung reduziert werden, die ein Maximum für die Größe der Datagramme festlegt, die sie senden wird.

Wenn die erste Sondierung der Größe größer oder gleich PLPMTU gesendet wird, wird PROBE_COUNT auf Null initialisiert. Jedes Sondierungspaket, das erfolgreich an den entfernten Peer gesendet wird, wird durch eine Bestätigung vom PL bestätigt (siehe Abschnitt 4.1).

Jedes Mal, wenn ein Sondierungspaket an das Ziel gesendet wird, wird der PROBE_TIMER gestartet. Der Timer wird abgebrochen, wenn der PL eine Bestätigung erhält, dass das Sondierungspaket erfolgreich über den Pfad gesendet wurde (Abschnitt 4.1). Dies bestätigt, dass PROBED_SIZE unterstützt wird, und der PROBED_SIZE-Wert wird dann PLPMTU zugewiesen. Der Suchalgorithmus kann fortfahren, nachfolgende Sondierungen mit zunehmender Größe zu senden.

Wenn der Timer abläuft, bevor ein Sondierungspaket bestätigt wird, hat die Sondierung PROBED_SIZE nicht bestätigt. Jedes Mal, wenn der PROBE_TIMER abläuft, wird PROBE_COUNT inkrementiert, der PROBE_TIMER wird neu initialisiert, und eine neue Sondierung derselben Größe oder jeder anderen Größe (wie vom Suchalgorithmus bestimmt) kann gesendet werden. Eine maximale Anzahl aufeinanderfolgender fehlgeschlagener Sondierungen (MAX_PROBES) ist konfiguriert. Wenn der Wert von PROBE_COUNT MAX_PROBES erreicht, stoppt die Sondierung, und der PL-Sender tritt in den SEARCH_COMPLETE-Zustand ein.

5.3.2. Auswahl von Sondierungsgrößen

Der Suchalgorithmus bestimmt die minimal nützliche Erhöhung der PLPMTU. Es ist nicht konstruktiv für den PL-Sender, alle Größen zu sondieren. Dies würde eine unnötige Last auf den Pfad legen. Implementierungen SOLLTEN eine Menge von Sondierungspaketgrößen auswählen, um den Gewinn in PLPMTU aus jedem Suchschritt zu maximieren.

Implementierungen können die Suchprozedur optimieren, indem sie Schrittgrößen aus einer Tabelle gängiger PMTU-Größen auswählen. Bei der Auswahl einer geeigneten nächsten Größe für die Suche sollten Implementierer auch gängige MPS-Größen berücksichtigen, die Anwendungen verwenden möchten, und dass es gängige MTU-Größen im Netzwerk geben könnte.

5.3.3. Resilienz gegen inkonsistente Pfadinformationen

Die Entscheidung, die PLPMTU zu erhöhen, muss gegen die Möglichkeit von Inkonsistenzen in den über den Netzwerkpfad gelernten Informationen resilient sein. Inkonsistenz im Pfad kann auftreten, wenn Sondierungspakete aus anderen Gründen als der Paketgröße verloren gehen (d.h. nicht größenbedingte Verluste) oder aufgrund häufiger Pfadänderungen. Häufige Pfadänderungen könnten aus unerwartetem "Jitter" resultieren -- wo einige Pakete eines Flusses entlang eines Pfades zugestellt werden, aber andere Pakete einem anderen Pfad mit unterschiedlichen Eigenschaften folgen.

Ein PL-Sender ist in der Lage, Inkonsistenz aus einer Sequenz von bestätigten PLPMTU-Sondierungen oder aus einer Sequenz von PTB-Nachrichten zu erkennen, die er empfängt. Ein PL-Sender kann ein alternatives Suchmuster verwenden, wenn er inkonsistente Pfadinformationen erkennt, eines, das die MPS, die für einen Zeitraum bereitgestellt wird, auf einen kleineren Wert begrenzt. Dies vermeidet unnötigen Paketverlust.

5.4. Robustheit gegen inkonsistente Pfade

Einige Pfade könnten nicht in der Lage sein, Pakete der Größe BASE_PLPMTU aufrechtzuerhalten. Der Fehlerzustand kann implementiert werden, um Robustheit für solche Pfade bereitzustellen. Dies ermöglicht einen Rückfall auf eine PLPMTU, die kleiner als gewünscht ist, anstatt einen Verbindungsfehler zu erleiden. Dies kann Methoden wie Endpunkt-IP-Fragmentierung nutzen, um dem PL-Sender zu ermöglichen, unter Verwendung von Paketen zu kommunizieren, die kleiner als BASE_PLPMTU sind.

Algorithmus-Zusammenfassung

Schlüsselelemente des DPLPMTUD-Algorithmus:

1. Konservativer Start: Beginnen von BASE_PLPMTU
2. Progressives Sondieren: Sondierungsgröße schrittweise erhöhen
3. Bestätigungsmechanismus: Verifizieren, dass jede Größe verfügbar ist
4. Schwarzes-Loch-Erkennung: Schnell auf Pfadprobleme reagieren
5. Periodische Wartung: PLPMTU auf dem neuesten Stand halten
6. Fehlerwiederherstellung: Außergewöhnliche Situationen handhaben

Diese Mechanismen stellen zusammen sicher, dass DPLPMTUD unter verschiedenen Netzwerkbedingungen zuverlässig und effizient arbeiten kann.