Zum Hauptinhalt springen

RFC 4379 - 4. Theory of Operation

4. Funktionstheorie (Theory of Operation)​

Ein MPLS echo request dient zum Testen eines bestimmten LSP. Das getestete LSP wird durch einen "FEC-Stapel" identifiziert; ist das LSP etwa über LDP zur Ausgangs-IP-Adresse 10.1.1.1 aufgebaut, enthält der FEC-Stapel ein einziges Element, das Sub-TLV LDP IPv4-Präfix mit Wert 10.1.1.1/32. Ist das getestete LSP ein RSVP-LSP, besteht der FEC-Stapel aus einem einzigen Element, das diesen LSP eindeutig durch RSVP-Sitzung und Sender-Template identifiziert.

Der FEC-Stapel kann komplexer sein. Etwa soll das VPN-IPv4-Präfix 10.1/8 über einen LDP-LSP-Tunnel mit Ausgang 10.10.1.1 getestet werden. Dann enthält der FEC-Stapel zwei Sub-TLVs, unten das VPN-IPv4-Präfix, oben das LDP-IPv4-Präfix. Ist der darunterliegende (LDP-)Tunnel unbekannt oder als irrelevant erachtet, kann der FEC-Stapel ein einziges Element mit nur dem VPN-IPv4-Sub-TLV sein.

Beim Empfang eines MPLS echo request wird vom Empfänger erwartet, dass er prüft, ob Kontroll- und Datenebene (für den gepingten FEC-Stapel) gesund und synchron sind. Das Verfahren ist in Abschnitt 4.4.

4.1. Umgang mit Equal-Cost Multi-Path (ECMP) (Dealing with Equal-Cost Multi-Path)​

Ein LSP muss kein einfacher Punkt-zu-Punkt-Tunnel sein. Ein einzelnes LSP beginnt oft an mehreren Eingängen und endet an mehreren Ausgängen (bei LDP-LSPs häufig). Ein LSP für einen gegebenen FEC kann am Transit-LSR auch mehrere "Next Hops" haben. Am Eingang können mehrere verschiedene LSP zur gewünschten Endstelle gewählt werden. Schließlich kann ein LSP Backup-Pfade, Umleitungspfade und andere alternative Pfade haben.

Die beiden letzten zuerst: Es wird angenommen, dass der initierende LSR den echo request in ein beliebiges gewünschtes LSP zwingen kann, weshalb die Wahl mehrerer LSP am Eingang kein Problem ist. Das Sondieren verschiedener Backup-Pfade (normalerweise nicht für die Datenweiterleitung genutzt, bis der Haupt-LSP ausfällt) wird hier nicht behandelt.

Da der tatsächlich genommene LSP/Pfad eines Pakets im Voraus unbekannt sein kann, wäre es nützlich, wenn ein MPLS echo request alle möglichen Pfade abdecken könnte. Das ist zwar ideal, aber weil der Algorithmus, mit dem jeder LSR Pakete auf verschiedene Pfade verteilt, proprietär sein kann, oft unrealistisch.

Um alternative Pfade teilweise abzudecken, besteht gewisse Freiheit bei der Wahl von Ziel-IP-Adresse und Quell-UDP-Port des echo request. Das allein ist offensichtlich unzureichend; im Traceroute-Fall bietet die Multipath-Information des Downstream-Mapping-TLV mehr Freiheit. Verwendung: Der Eingangs-LSR sendet periodisch MPLS-Traceroute-Nachrichten, um zu ermitteln, ob ein gegebenes LSP ein Multipath hat. Falls ja, liefert jeder Hop Informationen, wie seine Downstream-Pfade gesteuert werden. Der Eingang kann dann MPLS echo request senden, die diese Pfade abdecken. Hat mehr als ein LSR ECMP, KANN der Eingang Kombinationen versuchen, um alle Pfade abzudecken. Eine vollständige Abdeckung kann jedoch unerreichbar sein.

4.2. Testen von LSPs zum Tragen von MPLS-Nutzlasten (Testing LSPs That Are Used to Carry MPLS Payloads)​

Um manche LSP-Unterbrechungen zu erkennen, kann es nötig sein (MAY), den MPLS echo request beim Testen von LSPs, die MPLS-Nutzlasten tragen (wie LSPs für L2VPN- und L3VPN-Verkehr), mit mindestens einem zusätzlichen Label zu kapseln. Etwa kann das bloße Senden eines MPLS echo request beim Testen eines LDP- oder RSVP-TE-LSP nicht erkennen, dass ein Router unmittelbar oberhalb des LSP-ping-Ziels den echo request über eine Schnittstelle erfolgreich weitergeleitet hat, die nicht für das Tragen von MPLS-Nutzlasten konfiguriert ist, weil der Router Penultimate-Hop-Popping verwendet. Da der empfangende Router nicht unterscheiden kann, ob ein IP-Paket ohne Label oder mit Implicit-Null-Label gesendet wurde, verhindert ein Nil-FEC-Shim-Label über dem MPLS echo request, dass solche Pakete über eine nicht mit Label versehene Schnittstelle weitergeleitet werden.

4.3. Senden eines MPLS Echo Request (Sending an MPLS Echo Request)​

Ein MPLS echo request ist ein UDP-Paket. Der IP-Header wird wie folgt gesetzt: Quell-IP-Adresse ist eine routbare Adresse des Senders; Ziel-IP-Adresse ist eine (zufällig gewählte) Adresse aus 127/8 (IPv4) bzw. 0:0:0:0:0:FFFF:127/104 (IPv6). IP-TTL ist 1. Quell-UDP-Port vom Sender gewählt; Ziel-UDP-Port ist 3503 (von der IANA für MPLS echo request zugewiesen). Der IP-Header MUST die Router Alert-Option enthalten.

Der MPLS echo request wird mit dem Label-Stapel gesendet, der zum getesteten FEC passt. Hinweis: Führt das normale Routing zum FEC an der Stapelspitze etwa über einen Traffic-Engineering-Tunnel [RSVP-TE], können weitere Labels angewendet werden. Sind alle FECs im Stapel Implicit-Null-Labels zugeordnet, gilt der MPLS echo request auch bei zusätzlich angewendetem Label als ohne Label.

Hat der echo request ein Label, KANN (je nach Ping-Ziel) das TTL des innersten Labels auf 1 gesetzt werden, um zu verhindern, dass die Ping-Anfrage zu weit geht. Beispiele, wo dies SHOULD geschehen sollte, sind Ping eines VPN-IPv4- oder IPv6-Präfix, eines L2-VPN-Endpunkts oder eines Pseudowire. Das zu weite Gehen lässt sich auch durch Einfügen eines Router-Alert-Labels auf das Label verhindern; dies hat aber den unerwünschten Nebeneffekt, dass der MPLS echo request einen anderen Datenpfad als die echten Daten nehmen kann. Zur Verwendung dieser Mechanismen bei Pseudowire-Konnektivitätsprüfung siehe [VCCV].

Im "ping"-Modus (End-to-End-Konnektivitätsprüfung) ist das TTL des äußersten Labels 255. Im "traceroute"-Modus (Fehlerisolationsmodus) wird das TTL nacheinander auf 1, 2, ... gesetzt.

Der Sender wählt Sender's Handle und Sequence Number. Beim Senden weiterer MPLS echo request SOLLTE er Sequence Number um 1 erhöhen. Der Sender MAY aber eine Gruppe von echo request mit derselben Sequence Number senden, um die Chance zu erhöhen, dass mindestens eines mit dieser Sequence Number ankommt.

TimeStamp Sent wird auf die Sendezeit (Sekunden und Mikrosekunden) gesetzt. TimeStamp Received wird auf Null gesetzt.

Ein MPLS echo request MUST ein FEC-Stack-TLV haben. Zudem MUST der Antwortmodus auf den gewünschten gesetzt sein; Rückgabecode und -subcode sind Null. Im "traceroute"-Modus SOLLTE der echo request ein Downstream-Mapping-TLV enthalten.

4.4. Empfangen eines MPLS Echo Request (Receiving an MPLS Echo Request)​

Das Reichen eines MPLS echo request an die Kontrollebene wird durch eine der folgenden Paketausnahmen ausgelöst: Router Alert-Option, Ablauf des IP-TTL, Ablauf des MPLS-TTL, MPLS-Router-Alert-Label oder Zieladresse im Bereich 127/8. Die Kontrollebene identifiziert ihn zusätzlich über den UDP-Zielport 3503.

Zur Berichterstattung gilt der Stapelboden als Stack-Tiefe 1. Dies legt eine absolute Referenz für den Fall fest, dass der tatsächliche Stapel mehr Labels als die FECs im Ziel-FEC-Stapel enthalten kann.

Ferner bedeutet in allen hier aufgeführten Fehlercodes die Stack-Tiefe 0 "nicht angegebener Wert", zur Kompatibilität mit bestehenden Implementierungen, die das Rückgabe-Subcode-Feld nicht nutzen.

Der LSR X, der einen MPLS echo request empfängt, verfährt wie folgt:

  1. Die allgemeine Gültigkeit des Pakets prüfen. Ist das Paket fehlerhaft formatiert, SOLLTE LSR X einen MPLS Echo Reply mit Rückgabecode "Malformed echo request received", Subcode 0 senden. Gibt es ein nicht als "Ignore" markiertes und von X nicht verstandenes TLV, SOLLTE X einen passenden MPLS "TLV not understood", Subcode 0 senden; im letzteren Fall das nicht verstandene TLV nur als Sub-TLV im Errored TLVs-TLV der Antwort enthalten. Die Kopf-Felder Sender's Handle, Sequence Number und Timestamp Sent werden nicht geprüft, aber in der echo reply-Nachricht enthalten.

Der Algorithmus verwendet folgende Variablen und Kennungen:

  • Interface-I: Schnittstelle, die den MPLS echo request empfing.
  • Stack-R: Label-Stapel bei Empfang.
  • Stack-D: Label-Stapel im Downstream-Mapping-TLV (nicht zwingend vorhanden).
  • Label-L: das aus dem tatsächlichen Stapel gerade geprüfte Label. Nicht initialisiert.
  • Label-stack-depth: die geprüfte Label-Tiefe. Initialisiert mit der Zahl der Labels im empfangenen Stapel S.
  • FEC-stack-depth: die Tiefe des FEC im Ziel-FEC-Stapel, die auf das aktuelle tatsächliche Label angewendet wird. Nicht initialisiert.
  • Best-return-code: der derzeit bekannte beste echo reply-Rückgabecode. Kann sich mit weiteren Prüfungen ändern.
  • Best-rtn-subcode: wie Best-return-code, aber für den Echo-Reply-Subcode.
  • FEC-status: der von der FEC-Prüfung in Abschnitt 4.4.1 gelieferte Ergebniswert.

  1. Ist der echo request gültig, speichert LSR X die empfangene Schnittstelle in Interface-I und den Label-Stapel in Stack-R.

  2. Label-Validierung (Label Validation):

    Ist Label-stack-depth 0: setze FEC-stack-depth auf 1, Label-L auf 3 (Implicit Null); setze Best-return-code auf 3 ("Replying router is an egress for the FEC at stack depth"), Best-rtn-subcode auf den Wert FEC-stack-depth (1), gehe zu Schritt 5.

    Sonst entnehme Label-L aus Stack-R bei Tiefe Label-stack-depth, suche in der ILM, ob das Label zugewiesen und einer Operation zugeordnet ist. Gibt es keinen Eintrag für L: setze Best-return-code auf 11 ("No label entry at stack-depth"), Best-rtn-subcode auf Label-stack-depth, gehe zu Schritt 7. Sonst hole die zugehörige Label-Operation und gehe zu Schritt 4.

  3. Label-Operationsprüfung (Label Operation Check):

    Ist die Operation "Pop and Continue Processing" (einschließlich Explicit-Null- und Router-Alert-Label): verringere Label-stack-depth und iteriere zum nächsten Label, zurück zu Schritt 3.

    Ist die Operation "Swap or Pop and Switch based on Popped Label": setze Best-return-code auf 8 ("Label switched at stack-depth"), Best-rtn-subcode auf Label-stack-depth, um den Transit-Austausch zu melden. Enthält der empfangene echo request ein Downstream-Mapping-TLV: ist die IP-Adresse im TLV 127.0.0.1 oder 0::1, setze Best-return-code auf 6 ("Upstream Interface Index Unknown"), die Antwort SOLLTE ein Interface and Label Stack-TLV mit Interface-I und Stack-R enthalten. Sonst prüfe, ob IP-Adresse, Schnittstellenadresse und Label-Stapel des TLV mit Interface-I und Stack-R übereinstimmen; bei Abweichung setze Best-return-code auf 5 ("Downstream Mapping Mismatch"), die Antwort SOLLTE ein Interface and Label Stack-TLV auf Basis von Interface-I und Stack-R enthalten, gehe zu Schritt 7. Für jeden verfügbaren Downstream-ECMP-Pfad: hole die Ausgangsschnittstelle aus dem NHLFE-Eintrag; ist die Ausgangsschnittstelle nicht für MPLS aktiviert, setze Best-return-code auf 9 ("Label switched but no MPLS forwarding at stack-depth"), Best-rtn-subcode auf Label-stack-depth, gehe zu Send_Reply_Packet. Ist ein Downstream-Mapping-TLV vorhanden, SOLLTE die Antwort ein mit den Informationen des aktuellen ECMP-Pfads gefülltes Downstream-Mapping-TLV enthalten. Gibt es kein Downstream-Mapping-TLV oder ist die Downstream-IP-Adresse die ALLROUTERS-Multicast-Adresse, gehe zu Schritt 7. Ist das Flag "Validate FEC Stack" nicht gesetzt und der LSR nicht für standardmäßige FEC-Prüfung konfiguriert, gehe zu Schritt 7.

    FEC-stack-depth bestimmen: durchlaufe Stack-D des TLV von unten nach oben, verringere die Labelzahl für jedes nicht Implicit-Null-Label und erhöhe FEC-stack-depth für jedes Label; enthält es ein oder mehrere Implicit-Null-Labels, kann FEC-stack-depth größer als Label-stack-depth sein. Setze FEC-stack-depth auf 0, i auf Label-stack-depth; solange i>0: ++FEC-stack-depth; wenn Stack-D[FEC-stack-depth]!=3 (Implicit Null) dann --i. Ist die Zahl der Labels im FEC-Stapel >= FEC-stack-depth, führe das FEC-Prüfverfahren 4.4.1 aus; ist FEC-status 2, setze Best-return-code auf 10; ist der Rückgabecode 1, setze Best-return-code auf FEC-return-code, Best-rtn-subcode auf FEC-stack-depth. Gehe zu Schritt 7.

  4. Egress-Verarbeitung (Egress Processing): enthält der empfangene echo request kein Downstream-Mapping-TLV oder ist die Downstream-IP-Adresse 127.0.0.1 oder 0::1, gehe zu Schritt 6. Prüfe, ob IP-Adresse, Schnittstellenadresse und Label-Stapel des TLV mit Interface-I und Stack-R übereinstimmen; bei Abweichung setze Best-return-code auf 5, die Antwort SOLLTE ein Received Interface and Label Stack-TLV anlegen, gehe zu Schritt 7.

  5. Egress-FEC-Validierung (Egress FEC Validation): Schleife über alle Einträge des Ziel-FEC-Stapels ab FEC-stack-depth. Führe die FEC-Prüfung nach Abschnitt 4.4.1 auf Label-L und dem FEC bei FEC-stack-depth aus; setze Best-return-code auf FEC-code, Best-rtn-subcode auf den Wert FEC-stack-depth. Ist FEC-status 1, gehe zu Schritt 7. ++FEC-stack-depth; ist FEC-stack-depth > Zahl der FECs im Stapel, gehe zu Schritt 7. Ist FEC-status 0: ++Label-stack-depth; ist Label-stack-depth > Zahl der Labels in Stack-R, gehe zu Schritt 7; Label-L = Label aus Stack-R bei Tiefe Label-stack-depth; zurück zu Schritt 6.

  6. Antwortpaket senden (Send Reply Packet): sende einen MPLS echo reply mit Rückgabecode Best-return-code und Rückgabe-Subcode Best-rtn-subcode, einschließlich aller im Verlauf erzeugten TLVs. Das Sendeverfahren ist in 4.4.1.

4.4.1. FEC-Validierung (FEC Validation)​

Dieser Abschnitt beschreibt die Validierung eines FEC-Elements aus dem Ziel-FEC-Stapel und nimmt FEC, Label-L und Interface-I entgegen. Schritte:

  1. Die beiden Rückgabewerte FEC-status und FEC-return-code werden auf 0 initialisiert.
  2. Ist der FEC Nil FEC: ist Label-L Explicit_Null oder Router_Alert, zurück. Sonst setze FEC-return-code auf 10, FEC-status auf 1, zurück.
  3. Prüfe die FEC-Label-Abbildung, die beschreibt, wie der auf dem LSP empfangene Verkehr weiter ausgetauscht oder welcher Anwendung zugeordnet wird. Gibt es keine Abbildung, setze FEC-return-code auf 4 ("Replying router has no mapping for the FEC at stack-depth"), FEC-status auf 1, zurück.
  4. Ist die Label-Abbildung des FEC Implicit Null, setze FEC-status auf 2 und gehe zu Schritt 5. Sonst, ist die Label-Abbildung des FEC Label-L, gehe zu Schritt 5. Sonst setze FEC-return-code auf 10, FEC-status auf 1, zurück.
  5. Protokollprüfung: prüfe das Protokoll, das zur Bekanntgabe des FEC verwendet wird. Lässt sich feststellen, dass das mit Interface-I verknüpfte Protokoll diesen FEC-Typ nicht bekanntgeben wird, setze FEC-return-code auf 12 ("Protocol not associated with interface at FEC stack-depth"), FEC-status auf 1.
  6. Zurück.

4.5. Senden eines MPLS Echo Reply (Sending an MPLS Echo Reply)​

Ein MPLS echo reply ist ein UDP-Paket. Er MUST nur als Antwort auf einen MPLS echo request gesendet werden. Quell-IP-Adresse ist eine routbare Adresse des Antwortenden; Quellport ist der well-known UDP-Port von LSP ping. Ziel-IP-Adresse und UDP-Port werden aus der Quelle des echo request kopiert. IP-TTL ist 255. Ist der Antwortmodus der Anfrage "Reply via an IPv4 UDP packet with Router Alert", MUST der IP-Header die Router Alert-IP-Option enthalten; wird die Antwort über ein LSP gesendet, MUST das oberste Label das Router-Alert-Label (1) [LABEL-STACK] sein.

Das Format des echo reply entspricht dem des echo request. Sender's Handle, Sequence Number und TimeStamp Sent werden aus dem echo request kopiert; TimeStamp Received wird auf die Empfangszeit gesetzt (nützlich bei synchronen Uhren). Das FEC-Stack-TLV der Anfrage MAY in die Antwort kopiert werden.

Der Antwortende MUST den oben bestimmten Rückgabecode und -subcode füllen.

Enthält die Anfrage ein Pad-TLV, MUST der Antwortende das erste Byte bezüglich der Antwortart auswerten.

Ist der antwortende Router das Ziel des FEC, SOLLTE die echo reply kein Downstream-Mapping-TLV enthalten.

Enthält die Anfrage ein Downstream-Mapping-TLV und ist der Antwortende nicht das Ziel des FEC, SOLLTE er seine Downstream-Router und die entsprechenden Eingangs-Labels berechnen und der zurückgesandten echo reply für jeden Downstream-Router ein Downstream-Mapping-TLV hinzufügen.

Übersteigt die Verarbeitung der Multipath-Informationen des Downstream-Mapping-TLV das, was der empfangende Router leisten will, MAY er nur mit einer Teilmenge der Multipaths der Anfrage antworten. (Hinweis: Der Initiator MAY eine weitere echo request mit den in der Antwort fehlenden Multipath-Informationen senden.)

Außer Antwortmodus 4 ("Reply via application level control channel") wird der echo reply stets im Kontext des IP/MPLS-Netzwerks gesendet.

4.6. Empfangen eines MPLS Echo Reply (Receiving an MPLS Echo Reply)​

Der LSR X SOLLTE nur Antworten auf eigene gesendete MPLS echo request erhalten. Daher analysiert X bei Empfang eines echo reply das Paket, prüft dessen Gültigkeit und versucht, es über Ziel-UDP-Port und Sender's Handle einem früher gesendeten echo request zuzuordnen. Findet sich keine Übereinstimmung, verwirft X die Antwort; sonst prüft er die Sequence Number.

Enthält die Antwort ein Downstream-Mapping und will X den Traceroute fortsetzen, SOLLTE er das Downstream-Mapping in seinen nächsten echo request (TTL um 1 erhöht) kopieren.

4.7. Problem mit VPN-IPv4- und IPv6-Präfixen (Issue with VPN IPv4 and IPv6 Prefixes)​

Üblicherweise wird der LSP ping eines VPN-IPv4- oder IPv6-Präfix mit einem Label-Stapel der Tiefe > 1 gesendet, wobei das TTL des innersten Labels 1 ist, um beim PE-Ausgang zu enden, bevor das Kundengerät erreicht wird. In manchen Fällen kann sich der Label-Stapel vor Erreichen des PE-Ausgangs auf ein einzelnes Label reduzieren; dies beendet den ping vorzeitig. Ein Beispiel ist ein Carrier's-Carrier-VPN über mehrere AS.

Eine Umgehung: Ein solchen ping empfangender LSR erkennt das vorzeitige Ende und sendet Fehlercode 13 zurück. Der initiierende LSR kann dann den ping mit erhöhtem TTL des VPN-Labels wiederholen. So probiert der Eingangs-LSR nacheinander TTL-Werte, bis er den Wert findet, bei dem der VPN ping den PE-Ausgang erreicht.

4.8. Nicht konforme Router (Non-compliant Routers)​

Unterstützt das Egress des gepingten FEC-Stapels kein LSP ping, wird keine Antwort gesendet, was zu einem "falsch negativen" Ergebnis führen kann. Im "traceroute"-Modus antwortet ein Transit-LSR ohne LSP-ping-Unterstützung für einige TTL (etwa n) nicht. Der die echo request sendende LSR SOLLTE echo request mit TTL=n+1, n+2, ..., n+k senden, um LSR weiter downstream zu sondieren. In diesem Fall SOLLTE er für echo request mit TTL>n bis zum Empfang einer Antwort mit Downstream-Mapping-TLV das Feld "Downstream IP Address" des TLV auf die ALLROUTERS-Multicast-Adresse setzen. Der Label-Stapel MAY aus dem Downstream-Mapping-TLV entfallen. Zudem SOLLTE er bis zum Empfang eines echo reply mit Downstream-Mapping-TLV das Flag "Validate FEC Stack" nicht setzen.