3. Funktionen, die zur Bereitstellung von Datagram-PLPMTUD erforderlich sind

Die in [RFC4821] ausgedrückten Prinzipien gelten für die Verwendung der Technik mit jedem PL. TCP-PLPMTUD wurde unter Verwendung von Standard-TCP-Protokollmechanismen definiert. Im Gegensatz zu TCP erfordert ein Datagram-PL zusätzliche Mechanismen und Überlegungen zur Implementierung von PLPMTUD.

Anforderungen für Datagram-PLPMTUD

1. Verwaltung der PLPMTU

Für Datagram-PLs wird die PLPMTU von DPLPMTUD verwaltet. Ein PL DARF NICHT ein Datagramm (außer einem Sondierungspaket) mit einer Größe auf der PL senden, die größer als die aktuelle PLPMTU ist.

2. Sondierungspakete

Die Netzwerkschnittstelle unter dem PL ist ERFORDERLICH, um eine Möglichkeit zur Übertragung eines Sondierungspakets bereitzustellen, das größer als die PLPMTU ist.

• IPv4: Ein Sondierungspaket MUSS mit gesetztem Don't Fragment (DF)-Bit im IP-Header und ohne Netzwerkschicht-Endpunkt-Fragmentierung gesendet werden.
• IPv6: Ein Sondierungspaket wird immer ohne Quellfragmentierung gesendet (wie in [RFC8201] Abschnitt 5.4 spezifiziert).

3. Empfangsrückmeldung

Der Ziel-PL-Endpunkt ist ERFORDERLICH, um eine Rückmeldemethode bereitzustellen, die dem DPLPMTUD-Sender anzeigt, wann ein Sondierungspaket vom Ziel-PL-Endpunkt empfangen wurde. Abschnitt 6 liefert Beispiele dafür, wie ein PL diese Bestätigung empfangener Sondierungspakete bereitstellen kann.

4. Wiederherstellung bei Sondierungsverlust

Es wird EMPFOHLEN, Sondierungspakete zu verwenden, die keine Benutzerdaten transportieren, die im Falle eines Verlusts eine Neuübertragung erfordern würden. Die meisten Datagramm-Transporte erlauben dies.

Wenn ein Sondierungspaket Benutzerdaten enthält, die im Falle eines Verlusts eine Neuübertragung erfordern:

• Der PL (oder darüberliegende Schichten) ist ERFORDERLICH, jede Neuübertragung und/oder Reparatur eines resultierenden Verlusts zu arrangieren.
• Der PL ist ERFORDERLICH, im Fall robust zu sein, dass Sondierungspakete aus anderen Gründen verloren gehen (einschließlich Verbindungsübertragungsfehler, Überlastung).

5. PMTU-Parameter

• Ein DPLPMTUD-Sender wird EMPFOHLEN, Informationen über die maximale Größe des Pakets zu nutzen, das vom Sender über die lokale Verbindung übertragen werden kann (z.B. die lokale Verbindungs-MTU).
• Ein PL-Sender KANN ähnliche Informationen über die maximale Größe des Netzwerkschicht-Pakets nutzen, das ein Empfänger akzeptieren kann, wenn dies bereitgestellt wird (beachten Sie, dass dies kleiner als EMTU_R sein könnte).

Dies vermeidet, dass Implementierungen versuchen, Sondierungspakete zu senden, die nicht über die lokale Verbindung übertragen werden können. Ein zu hoher Wert könnte die Effizienz des Suchalgorithmus verringern. Einige Anwendungen haben auch eine maximale Transportprotokoll-Dateneinheitsgröße (PDU), in diesem Fall gibt es keinen Vorteil beim Sondieren einer Größe, die größer ist (es sei denn, ein Transport erlaubt das Multiplexen mehrerer Anwendungs-PDUs in dasselbe Datagramm).

6. Verarbeitung von PTB-Nachrichten

• Ein DPLPMTUD-Sender KANN optional PTB-Nachrichten nutzen, die von der Netzwerkschicht empfangen werden, um zu identifizieren, wann ein Netzwerkpfad die aktuelle Größe des Sondierungspakets nicht unterstützt.
• Jede empfangene PTB-Nachricht MUSS validiert werden, bevor sie zur Aktualisierung der PLPMTU-Erkennungsinformationen verwendet wird [RFC8201].

Diese Validierung bestätigt, dass die PTB-Nachricht als Antwort auf ein Paket gesendet wurde, das vom Endpunkt-PL stammt, der DPLPMTUD durchführt. Diese Validierung muss durchgeführt werden, bevor die PLPMTU-Erkennungsmethode auf die PTB-Nachricht reagiert.

• Eine PTB-Nachricht DARF NICHT verwendet werden, um die PLPMTU zu erhöhen [RFC8201].
• Eine PTB-Nachricht könnte eine Sondierung auslösen, um auf eine größere PLPMTU zu testen.

Ein gültiges PTB_SIZE wird in ein PL_PTB_SIZE umgewandelt, bevor es in der DPLPMTUD-Zustandsmaschine verwendet wird. Ein PL_PTB_SIZE, das größer als das aktuell sondierte ist, SOLLTE ignoriert werden (Diese PTB-Nachricht sollte ohne weitere Verarbeitung verworfen werden, könnte aber als Eingabe genutzt werden, die einen Resilienzmodus ermöglicht).

7. Sondierung und Überlastkontrolle

• Ein PL KANN einen Überlastcontroller verwenden, um zu entscheiden, wann ein Sondierungspaket gesendet werden soll.

Wenn die Übertragung von Sondierungspaketen durch den Überlastcontroller begrenzt wird, könnte dies dazu führen, dass die Übertragung von Sondierungspaketen während der Überlastung verzögert oder ausgesetzt wird.

• Wenn die Übertragung von Sondierungspaketen nicht durch den Überlastcontroller gesteuert wird, MUSS das Intervall zwischen Sondierungspaketen mindestens eine RTT betragen.
• Der Verlust eines Sondierungspakets SOLLTE NICHT als Hinweis auf Überlastung behandelt werden.
• Der Verlust eines Sondierungspakets SOLLTE NICHT eine Überlastkontrollreaktion auslösen [RFC4821].

Dies liegt daran, dass dies zu einer unnötigen Reduzierung der Senderate führen könnte.

• Eine Aktualisierung der PLPMTU (oder MPS) DARF NICHT das in Bytes gemessene Überlastfenster erhöhen [RFC4821].

Daher verursacht eine Erhöhung der Paketgröße keine Erhöhung der Datenrate in Bytes pro Sekunde. Ein PL, der das Überlastfenster in Bezug auf eine Begrenzung der Anzahl ausstehender Pakete fester Größe aufrechterhält, SOLLTE diese Begrenzung anpassen, um die Größe der tatsächlichen Pakete zu kompensieren.

Die Übertragung von Sondierungspaketen kann mit dem Betrieb eines PL interagieren, der Burst-Minderung oder Pacing durchführt, und der PL könnte benötigen, dass die Übertragung von Sondierungspaketen durch diese Methoden reguliert wird.

8. Sondierung und Flusskontrolle

Flusskontrolle auf der PL betrifft den Ende-zu-Ende-Fluss von Daten unter Verwendung des PL-Dienstes. Flusskontrolle SOLLTE NICHT auf DPLPMTUD angewendet werden, wenn Sondierungspakete ein Design verwenden, das keine Benutzerdaten zur entfernten Anwendung trägt.

9. Gemeinsam genutzter PLPMTU-Zustand

Der aus der PLPMTU berechnete PMTU-Wert KANN auch mit dem entsprechenden Eintrag gespeichert werden, der mit dem Ziel im IP-Schicht-Cache verbunden ist, und von anderen PL-Instanzen verwendet werden.

Die Spezifikation von PLPMTUD [RFC4821] besagt: „Wenn PLPMTUD die MTU für einen bestimmten Pfad aktualisiert, SOLLTEN alle Paketisierungsschicht-Sitzungen, die die Pfaddarstellung teilen (wie in Abschnitt 5.2 beschrieben), benachrichtigt werden, um die neue MTU zu verwenden". Solche Methoden MÜSSEN robust gegenüber der großen Vielfalt zugrunde liegender Netzwerk-Weiterleitungsverhalten sein. [RFC8201] Abschnitt 5.2 bietet Anleitungen zum Caching von PMTU-Informationen und auch zur Beziehung zu IPv6-Flusslabels.

Designprinzipien

Zusätzlich zu den obigen Anforderungen werden die folgenden Prinzipien für das Design einer DPLPMTUD-Methode angegeben:

1. Datensegmentierung

• Ein PL KANN so gestaltet sein, dass er Datenblöcke, die größer als die MPS sind, in mehrere Datagramme segmentiert.

Allerdings unterstützen nicht alle Datagramm-PLs die Segmentierung von Datenblöcken.

• Es wird EMPFOHLEN, dass Methoden vermeiden, eine Anwendung zu zwingen, eine willkürlich kleine MPS zur Übertragung zu verwenden, während die Methode nach der aktuell unterstützten PLPMTU sucht.

Eine reduzierte MPS kann die Leistung einer Anwendung beeinträchtigen.

2. MPS-Primitiv

Um Anwendungen bei der Auswahl einer geeigneten Datenblockgröße zu unterstützen, wird EMPFOHLEN, dass der PL ein Primitiv bereitstellt, das den aus der PLPMTU abgeleiteten MPS an die höhere Schicht zurückgibt, die den PL verwendet. Der Wert des MPS kann sich nach einer Änderung des Pfades oder dem Verlust von Sondierungspaketen ändern.

3. Pfadvalidierung

Es wird EMPFOHLEN, dass Methoden robust gegenüber Pfadänderungen sind, die seit der letzten Bestätigung der Pfadcharakteristiken aufgetreten sein könnten, und gegenüber der Möglichkeit inkonsistenter Pfadinformationen, die empfangen werden.

4. Datagramm-Neuordnung

Eine Methode ist ERFORDERLICH, robust gegenüber der Möglichkeit zu sein, dass ein Fluss auf Neuordnung stößt oder dass der Verkehr (einschließlich Sondierungspakete) über mehr als einen Netzwerkpfad aufgeteilt wird.

5. Datagramm-Verzögerung und Duplizierung

Der Rückmeldemechanismus ist ERFORDERLICH, robust gegenüber der Möglichkeit zu sein, dass Pakete entlang eines Netzwerkpfades erheblich verzögert oder dupliziert werden könnten.

6. Wann sondieren

Es wird EMPFOHLEN, dass Methoden bestimmen, ob sich der Pfad geändert hat, seit er zuletzt den Pfad gemessen hat. Dies kann helfen zu bestimmen, wann der Pfad erneut sondiert werden soll.

Implementierungsüberlegungen

Bei der Implementierung von DPLPMTUD berücksichtigen Sie:

1. Effizienz: Vermeiden Sie übermäßige Sondierung, die Netzwerk-Overhead verursacht
2. Robustheit: Behandeln Sie verschiedene Netzwerkbedingungen und Fehlerszenarien
3. Interoperabilität: Kompatibilität mit bestehenden Protokollen und Implementierungen
4. Leistung: Minimieren Sie die Auswirkungen auf die Anwendungsleistung

Diese Anforderungen und Prinzipien stellen sicher, dass DPLPMTUD unter verschiedenen Netzwerkbedingungen zuverlässig funktionieren kann.