3. Antworten

Dieser Abschnitt beantwortet die im vorigen Abschnitt gestellten Fragen.

A. Die Zuweisung von MPLS-Labels für spezielle Zwecke erfolgt über „Standards Action“.

B. Das IANA-Register wird in „Special-Purpose MPLS Label Values“ umbenannt.

C. Die frühe Zuweisung kann im Einzelfall erlaubt werden.

D. Der derzeitige Raum von 16 Labels für spezielle Zwecke ist zu klein, um Werte für experimentelle oder private Nutzung zu reservieren. Das in diesem Dokument erstellte Register „Extended Special-Purpose MPLS Label Values“ bietet jedoch genügend Platz, und dieses Dokument definiert einen Bereich für experimentelle Nutzung.

2. Ein Standards-Track-RFC muss eine Anfrage zur Zuweisung von Labels für spezielle Zwecke im Sinne von „Standards Action“ begleiten, wie in [RFC5226] festgelegt.

3. Die Außerbetriebnahme eines MPLS-Labelwerts für spezielle Zwecke muss einem strengen und gut dokumentierten Verfahren folgen. Dies ist erforderlich, weil vermieden werden muss, dass die Verwendung dieses Labelwerts in bestehenden Installationen verwaist. Dieses Verfahren ist in Abschnitt 3.2 beschrieben.

4. Vorerst wird die Verwendung des „Implicit NULL Label“ (Wert 3) in der Datenebene nicht erlaubt. Sollte diese Entscheidung später überdacht werden, ist ein begleitender Standards-Track-RFC erforderlich, der die Verwendung des Labels, eine Erörterung möglicher Verwechslungsquellen zwischen Signalisierung und Datenebene sowie deren Abwehr beschreibt.

5. Ein Label für spezielle Zwecke (das „Extension Label“, XL, Wert 15) wird für die Erweiterung des Raums der Labels für spezielle Zwecke reserviert. Weitere Einzelheiten sind in Abschnitt 3.1 beschrieben.

6. [RFC6790] besagt, dass Labels für spezielle Zwecke MUST NOT für die Lastverteilung verwendet werden. Dieselbe Logik gilt für erweiterte Labels für spezielle Zwecke (ESPLs). Daher legt dieses Dokument fest, dass ESPLs MUST NOT für die Lastverteilung verwendet werden. Es ist festzustellen, dass bestehende Implementierungen dem zuwiderhandeln würden, da sie XL nur als einzelnes Label für spezielle Zwecke erkennen und nicht erwarten, dass ein ESPL folgt. Die Folge ist, dass Pakete eines Flusses, in denen ESPLs verwendet werden, über verschiedene Pfade zugestellt und daher umgeordnet werden könnten. Es ist jedoch wichtig, das korrekte Verhalten für künftige Implementierungen festzulegen, daher die Verwendung von „MUST NOT“.

Eine weitere Frage, die in diesem Zusammenhang geklärt werden musste, war, ob ein „reguläres“ Label für spezielle Zwecke seine Bedeutung behält, wenn es auf das XL folgt. Die Antwort auf diese Frage wird in Abschnitt 3.1 gegeben.

3.1. Erweiterte MPLS-Labelwerte für spezielle Zwecke

Auf das XL MUST ein weiteres Label L folgen (und das XL muss daher das Bottom-of-Stack-Bit auf 0 gesetzt haben). L MUST als ESPL interpretiert und gemäß der Definition eines von diesem Dokument erstellten neuen Registers interpretiert werden (siehe Abschnitt 5). Ob L das Bottom-of-Stack-Bit gesetzt hat, hängt davon ab, ob weitere Labels auf L folgen. Das XL weist nur L eine besondere Bedeutung zu. Ein Label nach L (falls vorhanden) wird wie üblich analysiert und kann daher ein reguläres Label oder ein Label für spezielle Zwecke sein; im letzteren Fall kann es das XL sein und somit von einem weiteren ESPL gefolgt werden.

Der Labelwert 15 wird, wie in Abschnitt 5 dargestellt, als XL reserviert.

Die Werte 0-15 des Registers „Extended Special-Purpose MPLS Label Values“ sind als reserviert festgelegt. Darüber hinaus dürfen die Werte 0-6 und 8-15 MUST NOT in der Datenebene nach einem XL auftreten; ein LSR, der ein Paket mit einem XL an der Spitze des Label-Stacks verarbeitet, auf das ein Label mit dem Wert 0-6 oder 8-15 folgt, MUST das Paket verwerfen.

Das Label 7 behält bei Empfang seine Bedeutung als Entropy Label Indicator (ELI), unabhängig davon, ob es sich um ein reguläres Label für spezielle Zwecke oder um ein ESPL handelt; dies ist auf die Abwärtskompatibilität mit bereits implementiertem und eingesetztem Code und bereits eingesetzter Hardware zurückzuführen, die nach dem ELI sucht, ohne zu prüfen, ob das vorherige Label das XL ist. Wenn ein LSR jedoch ein Entropie-Label einfügt, MUST er das ELI als reguläres Label für spezielle Zwecke einfügen, nicht als ESPL.

3.1.1. Weiterleitung von Paketen mit erweiterten Labels für spezielle Zwecke

Trifft ein LSR auf das XL an der Stack-Spitze und versteht es keine Erweiterungslabels, so MUST er das Paket verwerfen, wie es für die Behandlung eines ungültigen eingehenden Labels gemäß [RFC3031] festgelegt ist. Trifft ein LSR an der Stack-Spitze (nach dem XL) auf ein ESPL, das es nicht versteht, so MUST er das Paket verwerfen, wobei er wiederum demselben Verfahren folgt. In beiden Fällen MAY der LSR das Ereignis protokollieren, doch eine solche Protokollierung MUST ratenbegrenzt sein.

Ein LSR SHOULD NOT Weiterleitungsentscheidungen auf der Grundlage von Labels treffen, die nicht an der Stack-Spitze stehen. Zu Lastverteilungsentscheidungen siehe Antwort 6 in Abschnitt 3.

3.1.2. Auswahl eines neuen Labels für spezielle Zwecke

Bei der Zuweisung eines neuen Labels für spezielle Zwecke sollten Protokollentwickler prüfen, ob sie ein erweitertes Label für spezielle Zwecke verwenden können. Dies würde helfen, die knappen Ressourcen „normaler“ Labels für spezielle Zwecke für Fälle zu bewahren, in denen die Minimierung der Größe des Label-Stacks besonders wichtig ist.

3.2. Verfahren zur Außerbetriebnahme von Labels für spezielle Zwecke

Das folgende Verfahren wird der Vollständigkeit halber definiert; beachten Sie jedoch, dass die Außerbetriebnahme von Labels für spezielle Zwecke schwierig ist. Es wird empfohlen, dieses Verfahren sparsam einzusetzen.

a. Ein aus dem Register „Special-Purpose MPLS Label Values“ zugewiesener Labelwert kann durch IETF-Konsens mit Prüfung durch die MPLS-Arbeitsgruppe (oder durch benannte Experten, falls die Arbeitsgruppe oder ein Nachfolger nicht existiert) als veraltet eingestuft werden. Erforderlich ist ein RFC mit mindestens dem Status Informational.

Der RFC wird IANA anweisen, den Labelwert im Register als „deprecated“ zu kennzeichnen, ihn in diesem Stadium jedoch nicht freizugeben.

Die Einstufung als veraltet bedeutet, dass keine weiteren Spezifikationen, die den veralteten Wert verwenden, dokumentiert werden.

Gleichzeitig ist dies ein Hinweis an Hersteller, den veralteten Wert nicht in neue Implementierungen aufzunehmen, und an Betreiber, ihn in neuen Installationen zu vermeiden.

b. Zwölf Monate nach Veröffentlichung des RFCs, der den Labelwert als veraltet einstuft, kann eine IETF-weite Umfrage durchgeführt werden, um festzustellen, ob der als veraltet eingestufte Labelwert noch verwendet wird. Ergibt die Umfrage, dass der als veraltet eingestufte Labelwert verwendet wird, kann die Umfrage nach weiteren 6 Monaten wiederholt werden.

c. Ergibt die Umfrage, dass ein als veraltet eingestufter Labelwert nicht verwendet wird, kann 24 Monate nach Veröffentlichung des RFCs, der den Labelwert als veraltet eingestuft hat, die Veröffentlichung eines IETF-Internet-Drafts der Standards Track beantragt werden, der den als veraltet eingestuften Labelwert außer Betrieb nimmt. Dieses Dokument wird IANA bitten, den Labelwert für zukünftige Nutzung und Zuweisung freizugeben.