3. Fragmentierung und Path MTU Discovery

3. Fragmentierung und Path MTU Discovery

   Genauso wie es möglich ist, ein ungelabeltes IP-Datagramm zu empfangen, das zu groß ist, um auf seiner Ausgangsverbindung übertragen zu werden, ist es möglich, ein gelabeltes Paket zu empfangen, das zu groß ist, um auf seiner Ausgangsverbindung übertragen zu werden.

   Es ist auch möglich, dass ein empfangenes Paket (gelabelt oder ungelabelt), das ursprünglich klein genug war, um auf dieser Verbindung übertragen zu werden, zu groß wird, weil ein oder mehrere zusätzliche Labels auf seinen Label Stack gelegt wurden. Beim Label Switching kann ein Paket an Größe zunehmen, wenn zusätzliche Labels hinzugefügt werden. Wenn man also ein gelabeltes Paket mit einer Frame Payload von 1500 Bytes empfängt und ein zusätzliches Label hinzufügt, muss man es als Frame mit einer Payload von 1504 Bytes weiterleiten.

   Dieser Abschnitt spezifiziert die Regeln für die Verarbeitung von gelabelten Paketen, die "zu groß" sind. Insbesondere werden Regeln bereitgestellt, die sicherstellen, dass Hosts, die Path MTU Discovery [4] implementieren, und Hosts, die IPv6 [7,8] verwenden, in der Lage sein werden, IP-Datagramme zu generieren, die keine Fragmentierung benötigen, selbst wenn diese Datagramme gelabelt werden, während sie das Netzwerk durchqueren.

   Im Allgemeinen senden IPv4-Hosts, die Path MTU Discovery [4] nicht implementieren, IP-Datagramme, die nicht mehr als 576 Bytes enthalten. Da die MTUs, die auf den meisten heutigen Datenverbindungen verwendet werden, 1500 Bytes oder mehr betragen, ist die Wahrscheinlichkeit, dass solche Datagramme fragmentiert werden müssen, selbst wenn sie gelabelt werden, sehr gering.

   Einige Hosts, die Path MTU Discovery [4] nicht implementieren, generieren IP-Datagramme mit 1500 Bytes, solange sich die IP-Quell- und Zieladressen im selben Subnetz befinden. Diese Datagramme passieren keine Router und werden daher nicht fragmentiert.

   Leider generieren einige Hosts IP-Datagramme mit 1500 Bytes, solange die IP-Quell- und Zieladressen dieselbe klassenvolle Netzwerknummer haben. Dies ist der einzige Fall, in dem ein Risiko der Fragmentierung besteht, wenn solche Datagramme gelabelt werden. (Selbst dann ist eine Fragmentierung nicht wahrscheinlich, es sei denn, das Paket muss eine Art von Ethernet durchqueren, zwischen dem Zeitpunkt, an dem es zum ersten Mal gelabelt wird, und dem Zeitpunkt, an dem es entlabelt wird.)

   Dieses Dokument spezifiziert Verfahren, die es ermöglichen, das Netzwerk so zu konfigurieren, dass große Datagramme von Hosts, die Path MTU Discovery nicht implementieren, nur einmal fragmentiert werden, wenn sie zum ersten Mal gelabelt werden. Diese Verfahren ermöglichen es (bei geeigneter Konfiguration), jede Notwendigkeit zu vermeiden, Pakete zu fragmentieren, die bereits gelabelt wurden.

3.1. Terminologie

In Bezug auf eine bestimmte Datenverbindung können wir die folgenden Begriffe verwenden:

  -  Frame Payload (Rahmennutzlast):

     Der Inhalt eines Datenverbindungsrahmens, ausgenommen alle Header oder Trailer der Datenverbindungsschicht (z. B. MAC-Header, LLC-Header, 802.1Q-Header, PPP-Header, Frame Check Sequences usw.).

     Wenn ein Rahmen ein ungelabeltes IP-Datagramm trägt, ist die Frame Payload einfach das IP-Datagramm selbst. Wenn ein Rahmen ein gelabeltes IP-Datagramm trägt, besteht die Frame Payload aus den Label Stack Entries und dem IP-Datagramm.

  -  Konventionelle Maximale Frame Payload Größe (Conventional Maximum Frame Payload Size):

     Die maximale Frame Payload Größe, die von Datenverbindungsstandards zugelassen wird. Beispielsweise beträgt die konventionelle maximale Frame Payload Größe für Ethernet 1500 Bytes.

  -  Wahre Maximale Frame Payload Größe (True Maximum Frame Payload Size):

     Die maximale Größe der Frame Payload, die von der an die Datenverbindung angeschlossenen Schnittstellenhardware ordnungsgemäß gesendet und empfangen werden kann.

     In Ethernet- und 802.3-Netzwerken wird angenommen, dass die Wahre Maximale Frame Payload Größe 4-8 Bytes größer ist als die Konventionelle Maximale Frame Payload Größe (solange weder ein 802.1Q-Header noch ein 802.1p-Header vorhanden ist und solange keiner von einem Switch oder einer Bridge hinzugefügt werden kann, während sich ein Paket auf dem Weg zu seinem nächsten Hop befindet). Beispielsweise wird angenommen, dass die meisten Ethernet-Geräte Pakete mit einer Payload von 1504 oder vielleicht sogar 1508 Bytes korrekt senden und empfangen könnten, zumindest solange der Ethernet-Header kein 802.1Q- oder 802.1p-Feld enthält.

     Auf PPP-Verbindungen kann die Wahre Maximale Frame Payload Größe praktisch unbegrenzt sein.

  -  Effektive Maximale Frame Payload Größe für Gelabelte Pakete (Effective Maximum Frame Payload Size for Labeled Packets):

     Dies ist entweder die Konventionelle Maximale Frame Payload Größe oder die Wahre Maximale Frame Payload Größe, abhängig von den Fähigkeiten der Ausrüstung auf der Datenverbindung und der Größe des verwendeten Datenverbindungs-Headers.

  -  Initial Gelabeltes IP-Datagramm (Initially Labeled IP Datagram):

     Angenommen, ein ungelabeltes IP-Datagramm wird an einem bestimmten LSR empfangen und der LSR fügt vor der Weiterleitung des Datagramms ein Label hinzu. Ein solches Datagramm wird an diesem LSR als Initial Gelabeltes IP-Datagramm bezeichnet.

  -  Zuvor Gelabeltes IP-Datagramm (Previously Labeled IP Datagram):

     Ein IP-Datagramm, das bereits gelabelt war, bevor es von einem bestimmten LSR empfangen wurde.

3.2. Maximale Größe des initial gelabelten IP-Datagramms

Jeder LSR, der fähig ist:

  a) ein ungelabeltes IP-Datagramm zu empfangen,
  b) einen Label Stack zum Datagramm hinzuzufügen, und
  c) das resultierende gelabelte Paket weiterzuleiten,

SOLLTE einen Konfigurationsparameter namens "Maximale Größe des initial gelabelten IP-Datagramms" unterstützen, der auf einen nicht negativen Wert gesetzt werden kann.

Wenn dieser Konfigurationsparameter auf null gesetzt ist, hat er keine Auswirkung.

Wenn er auf einen positiven Wert gesetzt ist, wird er auf folgende Weise verwendet. Wenn:

  a) ein ungelabeltes IP-Datagramm empfangen wird, und
  b) dieses Datagramm das DF-Bit in seinem IP-Header nicht gesetzt hat, und
  c) dieses Datagramm gelabelt werden muss, bevor es weitergeleitet wird, und
  d) die Größe des Datagramms (vor dem Labeling) den Wert des Parameters überschreitet,

dann a) muss das Datagramm in Fragmente zerlegt werden, von denen jedes eine Größe hat, die nicht größer als der Wert des Parameters ist, und

  b) jedes Fragment muss gelabelt und dann weitergeleitet werden.

Wenn dieser Konfigurationsparameter beispielsweise auf einen Wert von 1488 gesetzt ist, wird jedes ungelabelte IP-Datagramm, das mehr als 1488 Bytes enthält, vor dem Labeling fragmentiert. Jedes Fragment kann auf einer 1500-Byte-Datenverbindung ohne weitere Fragmentierung übertragen werden, selbst wenn bis zu drei Labels auf seinen Label Stack gelegt werden.

Mit anderen Worten, das Setzen dieses Parameters auf einen Wert ungleich null ermöglicht es, jegliche Fragmentierung von Zuvor Gelabelten IP-Datagrammen zu eliminieren, kann jedoch eine unnötige Fragmentierung von Initial Gelabelten IP-Datagrammen verursachen.

Beachten Sie, dass die Einstellung dieses Parameters die Verarbeitung von IP-Datagrammen, bei denen das DF-Bit gesetzt ist, nicht beeinflusst; daher bleibt das Ergebnis der Path MTU Discovery von der Einstellung dieses Parameters unberührt.

3.3. Wann sind gelabelte IP-Datagramme zu groß?

Ein gelabeltes IP-Datagramm, dessen Größe die Konventionelle Maximale Frame Payload Größe der Datenverbindung überschreitet, über die es weitergeleitet werden soll, KANN als "zu groß" betrachtet werden.

Ein gelabeltes IP-Datagramm, dessen Größe die Wahre Maximale Frame Payload Größe der Datenverbindung überschreitet, über die es weitergeleitet werden soll, MUSS als "zu groß" betrachtet werden.

Ein gelabeltes IP-Datagramm, das nicht "zu groß" ist, MUSS ohne Fragmentierung übertragen werden.

3.4. Verarbeitung von gelabelten IPv4-Datagrammen, die zu groß sind

Wenn ein gelabeltes IPv4-Datagramm "zu groß" ist und das DF-Bit in seinem IP-Header nicht gesetzt ist, KANN der LSR das Datagramm stillschweigend verwerfen.

Beachten Sie, dass das Verwerfen solcher Datagramme nur dann ein sinnvolles Verfahren ist, wenn die "Maximale Größe des initial gelabelten IP-Datagramms" in jedem LSR im Netzwerk, der in der Lage ist, einen Label Stack zu einem ungelabelten IP-Datagramm hinzuzufügen, auf einen Wert ungleich null gesetzt ist.

Wenn der LSR beschließt, ein gelabeltes IPv4-Datagramm, das zu groß ist, nicht zu verwerfen, oder wenn das DF-Bit in diesem Datagramm gesetzt ist, dann MUSS er den folgenden Algorithmus ausführen:

  1. Entferne die Label Stack Entries, um das IP-Datagramm zu erhalten.

  2. Sei N die Anzahl der Bytes im Label Stack (d. h. 4 mal die Anzahl der Label Stack Entries).

  3. Wenn das IP-Datagramm das "Don't Fragment"-Bit in seinem IP-Header NICHT gesetzt hat:

     a. Konvertiere es in Fragmente, von denen jedes mindestens N Bytes kleiner sein MUSS als die Effektive Maximale Frame Payload Größe.

     b. Stelle jedem Fragment denselben Label-Header voran, der auf dem ursprünglichen Datagramm gewesen wäre, wenn keine Fragmentierung erforderlich gewesen wäre.

     c. Leite die Fragmente weiter.

  4. Wenn das IP-Datagramm das "Don't Fragment"-Bit in seinem IP-Header gesetzt hat:

     a. Das Datagramm darf NICHT weitergeleitet werden.

     b. Erstelle eine ICMP Destination Unreachable Message:

         i. Setze ihr Code-Feld [3] auf "Fragmentation Required and DF Set",

        ii. Setze ihr Next-Hop MTU-Feld [4] auf die Differenz zwischen der Effektiven Maximalen Frame Payload Größe und dem Wert von N.

     c. Wenn möglich, übertrage die ICMP Destination Unreachable Message an die Quelle des verworfenen Datagramms.

3.5. Verarbeitung von gelabelten IPv6-Datagrammen, die zu groß sind

Um ein gelabeltes IPv6-Datagramm zu verarbeiten, das zu groß ist, MUSS ein LSR den folgenden Algorithmus ausführen:

  1. Entferne die Label Stack Entries, um das IP-Datagramm zu erhalten.

  2. Sei N die Anzahl der Bytes im Label Stack (d. h. 4 mal die Anzahl der Label Stack Entries).

  3. Wenn das IP-Datagramm mehr als 1280 Oktette enthält (ohne die Label Stack Entries zu zählen) oder wenn es keinen Fragment-Header enthält, dann:

     a. Erstelle eine ICMP Packet Too Big Message und setze ihr Next-Hop MTU-Feld auf die Differenz zwischen der Effektiven Maximalen Frame Payload Größe und dem Wert von N.

     b. Wenn möglich, übertrage die ICMP Packet Too Big Message an die Quelle des Datagramms.

     c. Verwerfe das gelabelte IPv6-Datagramm.

  4. Wenn das IP-Datagramm nicht größer als 1280 Oktette ist und einen Fragment-Header enthält, dann

     a. Konvertiere es in Fragmente, von denen jedes mindestens N Bytes kleiner sein MUSS als die Effektive Maximale Frame Payload Größe.

     b. Stelle jedem Fragment denselben Label-Header voran, der auf dem ursprünglichen Datagramm gewesen wäre, wenn keine Fragmentierung erforderlich gewesen wäre.

     c. Leite die Fragmente weiter.

     Das Wiederzusammensetzen der Fragmente erfolgt am Zielhost.

3.6. Auswirkungen in Bezug auf Path MTU Discovery

Die oben beschriebenen Verfahren zur Behandlung von Datagrammen, bei denen das DF-Bit gesetzt ist, die aber "zu groß" sind, haben Auswirkungen auf die Path MTU Discovery-Verfahren von RFC 1191 [4]. Hosts, die diese Verfahren implementieren, werden eine MTU entdecken, die klein genug ist, um n Labels auf die Datagramme zu legen, ohne dass eine Fragmentierung erforderlich ist, wobei n die Anzahl der Labels ist, die tatsächlich entlang des aktuell verwendeten Pfades hinzugefügt werden.

Mit anderen Worten, Datagramme von Hosts, die Path MTU Discovery verwenden, müssen niemals aufgrund der Notwendigkeit, einen Label-Header hinzuzufügen oder neue Labels zu einem bestehenden Label-Header hinzuzufügen, fragmentiert werden. (Außerdem haben Datagramme von Hosts, die Path MTU Discovery verwenden, im Allgemeinen das DF-Bit gesetzt und werden daher sowieso nicht fragmentiert.)

Beachten Sie, dass Path MTU Discovery nur dann ordnungsgemäß funktioniert, wenn an dem Punkt, an dem die Fragmentierung eines gelabelten IP-Datagramms erfolgen muss, eine ICMP Destination Unreachable Message an die Quelladresse des Pakets geroutet werden kann. Siehe Abschnitt 2.3.

Wenn es nicht möglich ist, eine ICMP-Nachricht aus einem MPLS-"Tunnel" an die Quelladresse eines Pakets weiterzuleiten, aber die Netzwerkkonfiguration es dem LSR am sendenden Ende des Tunnels ermöglicht, Pakete zu empfangen, die durch den Tunnel gehen müssen, aber zu groß sind, um den Tunnel unfragmentiert zu passieren, dann:

  -  Der LSR am sendenden Ende des Tunnels MUSS in der Lage sein, die MTU des gesamten Tunnels zu bestimmen. Er KANN dies tun, indem er Pakete durch den Tunnel an den empfangenden Endpunkt des Tunnels sendet und mit diesen Paketen Path MTU Discovery durchführt.

  -  Jedes Mal, wenn der sendende Endpunkt des Tunnels ein Paket in den Tunnel senden muss und dieses Paket das DF-Bit gesetzt hat und die Tunnel-MTU überschreitet, MUSS der sendende Endpunkt des Tunnels die ICMP Destination Unreachable Message mit dem Code "Fragmentation Required and DF Set" und dem wie oben beschriebenen Next-Hop MTU-Feld an die Quelle senden.