Zum Hauptinhalt springen

2. Der Label Stack

  1. Der Label Stack

2.1. Codierung des Label Stacks

Der Label Stack wird als eine Sequenz von "Label Stack Entries" (Label-Stack-Einträgen) dargestellt. Jeder Label Stack Entry wird durch 4 Oktette dargestellt. Dies ist in Abbildung 1 dargestellt.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | Exp |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                Label:  Label-Wert, 20 Bits
                Exp:    Experimentelle Nutzung, 3 Bits
                S:      Bottom of Stack (Stapelende), 1 Bit
                TTL:    Time to Live, 8 Bits

                          Abbildung 1

Die Label Stack Entries erscheinen NACH den Datenverbindungsschicht-Headern, aber VOR allen Netzwerkschicht-Headern. Das obere Ende des Label Stacks erscheint am frühesten im Paket, und das untere Ende erscheint am spätesten. Das Netzwerkschichtpaket folgt unmittelbar auf den Label Stack Entry, bei dem das S-Bit gesetzt ist.

Jeder Label Stack Entry ist in die folgenden Felder unterteilt:

  1. Bottom of Stack (S)

     Dieses Bit wird für den letzten Eintrag im Label Stack (d. h. für das Stapelende) auf eins gesetzt und für alle anderen Label Stack Entries auf null.

  2. Time to Live (TTL)

     Dieses 8-Bit-Feld wird verwendet, um einen Time-to-Live-Wert zu codieren. Die Verarbeitung dieses Feldes wird in Abschnitt 2.4 beschrieben.

  3. Experimentelle Nutzung (Exp)

     Dieses 3-Bit-Feld ist für die experimentelle Nutzung reserviert.

  4. Label-Wert (Label Value)

     Dieses 20-Bit-Feld trägt den tatsächlichen Wert des Labels.

     Wenn ein gelabeltes Paket empfangen wird, wird der Label-Wert oben auf dem Stapel nachgeschlagen. Als Ergebnis eines erfolgreichen Nachschlagens erfährt man:

     a) den nächsten Hop, an den das Paket weitergeleitet werden soll;

     b) die Operation, die auf dem Label Stack vor der Weiterleitung ausgeführt werden soll; diese Operation kann darin bestehen, den obersten Label Stack Entry durch einen anderen zu ersetzen, oder einen Eintrag vom Label Stack zu entfernen (pop), oder den obersten Label Stack Entry zu ersetzen und dann einen oder mehrere zusätzliche Einträge auf den Label Stack zu legen (push).

     Zusätzlich zum Erlernen des nächsten Hops und der Label Stack-Operation kann man auch die ausgehende Datenverbindungskapselung und möglicherweise andere Informationen erfahren, die benötigt werden, um das Paket ordnungsgemäß weiterzuleiten.

     Es gibt mehrere reservierte Label-Werte:

       i. Ein Wert von 0 repräsentiert das "IPv4 Explicit NULL Label". Dieser Label-Wert ist nur am unteren Ende des Label Stacks zulässig. Er zeigt an, dass der Label Stack entfernt werden muss und die Weiterleitung des Pakets dann basierend auf dem IPv4-Header erfolgen muss.

      ii. Ein Wert von 1 repräsentiert das "Router Alert Label". Dieser Label-Wert ist überall im Label Stack zulässig, außer am unteren Ende. Wenn ein empfangenes Paket diesen Label-Wert oben auf dem Label Stack enthält, wird es zur Verarbeitung an ein lokales Softwaremodul übergeben. Die tatsächliche Weiterleitung des Pakets wird durch das Label darunter im Stapel bestimmt. Wenn das Paket jedoch weitergeleitet wird, sollte das Router Alert Label vor der Weiterleitung wieder auf den Label Stack gelegt werden. Die Verwendung dieses Labels ist analog zur Verwendung der "Router Alert Option" in IP-Paketen [5]. Da dieses Label nicht am unteren Ende des Stapels auftreten kann, ist es keinem bestimmten Netzwerkschichtprotokoll zugeordnet.

     iii. Ein Wert von 2 repräsentiert das "IPv6 Explicit NULL Label". Dieser Label-Wert ist nur am unteren Ende des Label Stacks zulässig. Er zeigt an, dass der Label Stack entfernt werden muss und die Weiterleitung des Pakets dann basierend auf dem IPv6-Header erfolgen muss.

      iv. Ein Wert von 3 repräsentiert das "Implicit NULL Label". Dies ist ein Label, das ein LSR zuweisen und verteilen kann, das jedoch niemals tatsächlich in der Kapselung erscheint. Wenn ein LSR andernfalls das Label oben auf dem Stapel durch ein neues Label ersetzen würde, das neue Label jedoch "Implicit NULL" ist, wird der LSR den Stapel entfernen, anstatt die Ersetzung vorzunehmen. Obwohl dieser Wert möglicherweise nie in der Kapselung erscheint, muss er im Label Distribution Protocol spezifiziert werden, daher ist ein Wert reserviert.

       v. Die Werte 4-15 sind reserviert.

2.2. Bestimmung des Netzwerkschichtprotokolls

Wenn das letzte Label vom Label Stack eines Pakets entfernt wird (was dazu führt, dass der Stapel geleert wird), basiert die weitere Verarbeitung des Pakets auf dem Netzwerkschicht-Header des Pakets. Der LSR, der das letzte Label vom Stapel entfernt, muss daher in der Lage sein, das Netzwerkschichtprotokoll des Pakets zu identifizieren. Der Label Stack enthält jedoch kein Feld, das das Netzwerkschichtprotokoll explizit identifiziert. Dies bedeutet, dass die Identität des Netzwerkschichtprotokolls aus dem Wert des Labels abgeleitet werden muss, das vom unteren Ende des Stapels entfernt wird, möglicherweise zusammen mit dem Inhalt des Netzwerkschicht-Headers selbst.

Daher muss, wenn das erste Label auf ein Netzwerkschichtpaket gelegt wird, das Label entweder eines sein, das NUR für Pakete einer bestimmten Netzwerkschicht verwendet wird, oder das Label muss eines sein, das NUR für einen bestimmten Satz von Netzwerkschichtprotokollen verwendet wird, wobei Pakete der spezifizierten Netzwerkschichten durch Inspektion des Netzwerkschicht-Headers unterschieden werden können. Darüber hinaus muss, wann immer dieser Label-Wert während des Transits eines Pakets durch einen anderen Label-Wert ersetzt wird, der neue Wert ebenfalls einer sein, der die gleichen Kriterien erfüllt. Wenn diese Bedingungen nicht erfüllt sind, kann der LSR, der das letzte Label von einem Paket entfernt, das Netzwerkschichtprotokoll des Pakets nicht identifizieren.

Die Einhaltung dieser Bedingungen ermöglicht es Zwischenknoten nicht unbedingt, das Netzwerkschichtprotokoll eines Pakets zu identifizieren. Unter normalen Bedingungen ist dies nicht erforderlich, aber es gibt Fehlerbedingungen, unter denen dies wünschenswert ist. Wenn beispielsweise ein zwischengeschalteter LSR feststellt, dass ein gelabeltes Paket unzustellbar ist, kann es für diesen LSR wünschenswert sein, Fehlermeldungen zu generieren, die spezifisch für die Netzwerkschicht des Pakets sind. Das einzige Mittel, das der zwischengeschaltete LSR zur Identifizierung der Netzwerkschicht hat, ist die Inspektion des obersten Labels und des Netzwerkschicht-Headers. Wenn also Zwischenknoten in der Lage sein sollen, protokollspezifische Fehlermeldungen für gelabelte Pakete zu generieren, müssen alle Labels im Stapel die oben spezifizierten Kriterien für Labels erfüllen, die am unteren Ende des Stapels erscheinen.

Wenn ein Paket aus irgendeinem Grund nicht weitergeleitet werden kann (z. B. überschreitet es die Datenverbindungs-MTU) und entweder sein Netzwerkschichtprotokoll nicht identifiziert werden kann oder es keine spezifizierten protokollabhängigen Regeln für die Behandlung der Fehlerbedingung gibt, MUSS das Paket stillschweigend verworfen werden.

2.3. Generierung von ICMP-Nachrichten für gelabelte IP-Pakete

Abschnitt 2.4 und Abschnitt 3 diskutieren Situationen, in denen es wünschenswert ist, ICMP-Nachrichten für gelabelte IP-Pakete zu generieren. Damit ein bestimmter LSR ein ICMP-Paket generieren und dieses Paket an die Quelle des IP-Pakets senden kann, müssen zwei Bedingungen erfüllt sein:

  1. Es muss für diesen LSR möglich sein, zu bestimmen, dass ein bestimmtes gelabeltes Paket ein IP-Paket ist;

  2. Es muss für diesen LSR möglich sein, zur IP-Quelladresse des Pakets zu routen.

Bedingung 1 wird in Abschnitt 2.2 diskutiert. Die folgenden zwei Unterabschnitte diskutieren Bedingung 2. Es wird jedoch einige Fälle geben, in denen Bedingung 2 überhaupt nicht zutrifft, und in diesen Fällen wird es nicht möglich sein, die ICMP-Nachricht zu generieren.

2.3.1. Tunneling durch eine Transit-Routing-Domäne

Angenommen, man verwendet MPLS, um durch eine Transit-Routing-Domäne zu "tunneln", wobei die externen Routen nicht in die internen Router der Domäne gelangen. Beispielsweise können die internen Router OSPF ausführen und wissen möglicherweise nur, wie Ziele innerhalb dieser OSPF-Domäne erreicht werden können. Die Domäne könnte mehrere Autonomous System Border Routers (ASBRs) enthalten, die BGP miteinander sprechen. In diesem Beispiel werden die Routen von BGP jedoch nicht in OSPF verteilt, und die LSRs, die keine ASBRs sind, führen kein BGP aus.

In diesem Beispiel weiß nur ein ASBR, wie zur Quelle eines beliebigen Pakets geroutet werden kann. Wenn ein interner Router eine ICMP-Nachricht an die Quelle eines IP-Pakets senden muss, weiß er nicht, wie die ICMP-Nachricht geroutet werden soll.

Eine Lösung besteht darin, dass einer oder mehrere der ASBRs "Default" in das IGP injizieren. (N.B.: Dies erfordert NICHT, dass ein "Default" von BGP getragen wird.) Dies würde dann sicherstellen, dass jedes ungelabelte Paket, das die Domäne verlassen muss (wie ein ICMP-Paket), an einen Router gesendet wird, der über vollständige Routing-Informationen verfügt. Die Router mit vollständigen Routing-Informationen werden die Pakete labeln, bevor sie sie durch die Transit-Domäne zurücksenden, sodass die Verwendung von Default-Routing innerhalb der Transit-Domäne keine Schleifen verursacht.

Diese Lösung funktioniert nur für Pakete, die global eindeutige Adressen haben, und für Netzwerke, in denen alle ASBRs über vollständige Routing-Informationen verfügen. Der nächste Unterabschnitt beschreibt eine Lösung, die funktioniert, wenn diese Bedingungen nicht erfüllt sind.

2.3.2. Tunneling privater Adressen durch einen öffentlichen Backbone

In einigen Fällen, in denen MPLS verwendet wird, um durch eine Routing-Domäne zu tunneln, ist es möglicherweise überhaupt nicht möglich, zur Quelladresse eines fragmentierten Pakets zu routen. Dies wäre beispielsweise der Fall, wenn die im Paket getragenen IP-Adressen private (d. h. nicht global eindeutige) Adressen wären und MPLS verwendet würde, um diese Pakete durch einen öffentlichen Backbone zu tunneln. Default-Routing zu einem ASBR funktioniert in dieser Umgebung nicht.

In dieser Umgebung kann man, um eine ICMP-Nachricht an die Quelle eines Pakets zu senden, den Label Stack vom ursprünglichen Paket in die ICMP-Nachricht kopieren und dann die ICMP-Nachricht per Label Switching übertragen. Dies führt dazu, dass die Nachricht in Richtung des Ziels des ursprünglichen Pakets und nicht zu seiner Quelle weitergeleitet wird. Sofern die Nachricht nicht den ganzen Weg zum Zielhost per Label Switching übertragen wird, landet sie ungelabelt in einem Router, der weiß, wie zur Quelle des ursprünglichen Pakets geroutet werden kann, woraufhin die Nachricht in die richtige Richtung gesendet wird.

Diese Technik kann sehr nützlich sein, wenn die ICMP-Nachricht eine "Time Exceeded"-Nachricht oder eine "Destination Unreachable because fragmentation needed and DF set"-Nachricht ist.

Beim Kopieren des Label Stacks vom ursprünglichen Paket in die ICMP-Nachricht müssen die Label-Werte exakt kopiert werden, aber die TTL-Werte im Label Stack sollten auf den TTL-Wert gesetzt werden, der im IP-Header der ICMP-Nachricht platziert ist. Dieser TTL-Wert sollte lang genug sein, um die umständliche Route zu ermöglichen, der die ICMP-Nachricht folgen muss.

Beachten Sie, dass, wenn der TTL-Ablauf eines Pakets auf das Vorhandensein einer Routing-Schleife zurückzuführen ist, die ICMP-Nachricht bei Verwendung dieser Technik ebenfalls in einer Schleife laufen kann. Da eine ICMP-Nachricht niemals als Ergebnis des Empfangs einer ICMP-Nachricht gesendet wird und da viele Implementierungen die Rate drosseln, mit der ICMP-Nachrichten generiert werden können, wird nicht erwartet, dass dies ein Problem darstellt.

2.4. Verarbeitung des Time to Live (TTL)-Feldes

2.4.1. Definitionen

Der "eingehende TTL" eines gelabelten Pakets ist definiert als der Wert des TTL-Feldes des obersten Label Stack Entry, wenn das Paket empfangen wird.

Der "ausgehende TTL" eines gelabelten Pakets ist definiert als der größere von:

  a) eins weniger als der eingehende TTL,
  b) null.

2.4.2. Protokollunabhängige Regeln

Wenn der ausgehende TTL eines gelabelten Pakets 0 ist, darf das gelabelte Paket NICHT weitergeleitet werden; auch darf der Label Stack nicht entfernt und das Paket als ungelabeltes Paket weitergeleitet werden. Die Lebensdauer des Pakets im Netzwerk gilt als abgelaufen.

Abhängig vom Label-Wert im Label Stack Entry KANN das Paket einfach verworfen werden, oder es kann an die entsprechende "gewöhnliche" Netzwerkschicht zur Fehlerverarbeitung übergeben werden (z. B. zur Generierung einer ICMP-Fehlermeldung, siehe Abschnitt 2.3).

Wenn ein gelabeltes Paket weitergeleitet wird, MUSS das TTL-Feld des Label Stack Entry oben auf dem Label Stack auf den ausgehenden TTL-Wert gesetzt werden.

Beachten Sie, dass der ausgehende TTL-Wert ausschließlich eine Funktion des eingehenden TTL-Wertes ist und unabhängig davon ist, ob Labels vor der Weiterleitung hinzugefügt oder entfernt werden. Der Wert des TTL-Feldes in einem Label Stack Entry, der sich nicht oben auf dem Stapel befindet, hat keine Bedeutung.

2.4.3. IP-abhängige Regeln

Wir definieren das "IP TTL"-Feld als den Wert des IPv4 TTL-Feldes oder den Wert des IPv6 Hop Limit-Feldes, je nachdem, was zutrifft.

Wenn ein IP-Paket zum ersten Mal gelabelt wird, MUSS das TTL-Feld des Label Stack Entry auf den Wert des IP TTL-Feldes gesetzt werden. (Wenn das IP TTL-Feld als Teil der IP-Verarbeitung dekrementiert werden muss, wird angenommen, dass dies bereits geschehen ist.)

Wenn ein Label entfernt wird und der resultierende Label Stack leer ist, SOLLTE der Wert des IP TTL-Feldes durch den ausgehenden TTL-Wert ersetzt werden, wie oben definiert. In IPv4 erfordert dies auch eine Modifikation der IP-Header-Prüfsumme.

Es wird anerkannt, dass es Situationen geben kann, in denen eine Netzwerkadministration es vorzieht, den IPv4 TTL um eins zu dekrementieren, wenn er eine MPLS-Domäne durchquert, anstatt den IPv4 TTL um die Anzahl der LSP-Hops innerhalb der Domäne zu dekrementieren.

2.4.4. Übersetzung zwischen verschiedenen Kapselungen

Manchmal kann ein LSR ein gelabeltes Paket über z. B. eine Label Switching Controlled ATM (LC-ATM)-Schnittstelle [9] empfangen und muss es möglicherweise über eine PPP- oder LAN-Verbindung senden. Dann wird das eingehende Paket nicht unter Verwendung der in diesem Dokument spezifizierten Kapselung empfangen, aber das ausgehende Paket wird unter Verwendung der in diesem Dokument spezifizierten Kapselung gesendet.

In diesem Fall wird der Wert des "eingehenden TTL" durch die Verfahren bestimmt, die zum Tragen von gelabelten Paketen auf z. B. LC-ATM-Schnittstellen verwendet werden. Die TTL-Verarbeitung erfolgt dann wie oben beschrieben.

Manchmal kann ein LSR ein gelabeltes Paket über eine PPP- oder LAN-Verbindung empfangen und muss es möglicherweise über, sagen wir, eine LC-ATM-Schnittstelle senden. Dann wird das eingehende Paket unter Verwendung der in diesem Dokument spezifizierten Kapselung empfangen, aber das ausgehende Paket wird nicht unter Verwendung der in diesem Dokument spezifizierten Kapselung gesendet. In diesem Fall wird das Verfahren zum Tragen des Wertes des "ausgehenden TTL" durch die Verfahren bestimmt, die zum Tragen von gelabelten Paketen auf z. B. LC-ATM-Schnittstellen verwendet werden.

Letztes Update am