Zusammenfassung

  • Ein TTL-Ablauf kann einen Zwischenpunkt zum Responder machen. Eine erfolgreiche Antwort ist daher kein Beleg dafür, dass der Ziel-Egress oder ein beabsichtigter Rückweg erreicht wurde.
  • Der Requester besitzt die Autorität über Probe, TTL, Reply-Modus, Kapselung und die optionale Anforderung von Reverse-FEC-Informationen. Der Responder besitzt nur Autorität über seine Antwort und lokale, prüfbare Fakten.
  • Der Requester muss Interface, Label Stack und einschlägige FEC prüfen; ist ein Reverse-path Target FEC Stack TLV vorhanden, muss er auch diesen prüfen. Bei fehlgeschlagener Prüfung ist die Antwort zu verwerfen und der Befund sollte gemeldet werden.

RFC 6426 erweitert LSP Ping um On-Demand-CV und Route Tracing für MPLS-TP. Bei IP-Kapselung wird eine Adresse aus 127/8 und UDP innerhalb des MPLS-Stacks verwendet. Der Nicht-IP-Betrieb nutzt ACH und ist nicht von IP-Routing abhängig. Bei Nicht-IP-ACH mit reply mode 4 muss die Antwort über den Reverse-LSP mittels ACH und ohne IP/UDP laufen. Hat ein Knoten keinen solchen Rückweg, sollte er die Anfrage verwerfen; Schweigen ist dann kein positiver Nachweis und eine alternative Antwort darf nicht als Ersatz gelten.

Requester und Responder sind getrennt zu beurteilen. Der Requester legt Ziel-FEC, TTL, Kapselung und Reply-Modus fest und kann mit gesetztem R flag Reverse-Path-FEC-Informationen anfordern. Das R flag darf in der Echo-Antwort nicht gesetzt sein. Wenn R in der Anfrage gesetzt ist, soll der Responder den Reverse-path Target FEC Stack TLV beifügen. Co-routed und zugeordnete bidirektionale LSPs können dennoch unterschiedliche Reverse-FEC-Beziehungen haben. Der bloße Empfang einer Antwort und eine Antwort ohne R beweisen daher keinen Reverse-FEC.

Für die Annahme muss der Requester Source Identifier TLV, Destination Identifier TLV, TTL, Empfangsinterface, Label Stack, Target FEC, Reply-Modus und Kapselung korrelieren. Ist ein Reverse-path Target FEC Stack TLV vorhanden, muss auch dieser zur erwarteten Beziehung passen. Die Regel gilt für statisch eingerichtete LSP- und PW-FECs ebenso wie für Nicht-IP-Pfade. Über administrative Grenzen empfiehlt RFC 6426 Source Identifier TLVs, damit unerwartete oder unbekannte Quellen gefiltert werden können.

Das GAL ist Träger für OAM, nicht die zu verifizierende FEC im Label Stack. Es darf kein Nil FEC TLV erhalten und nicht in DSMAP/DDMAP erscheinen; Interface- und Label-Stack-TLVs können es dagegen enthalten. Wer GAL als Ziel-FEC liest, verschiebt die Evidenz und kommt zu einem unzulässigen Schluss.

On-Demand-Route-Tracing verwendet DSMAP/DDMAP und TTL-Ablauf, um Anfragen an bestimmte Punkte eines LSP zu lenken. Eine konkrete Prüfinstanz kann einen bekannten statischen FEC mit reply mode 4 und bekannten Source-/Destination-Identifiern senden und TTL=1, TTL=2 und TTL=3 getrennt ausführen. Für jede Antwort sind TTL-Endpunkt, Quellidentität, Interface, Label Stack, Target FEC, R im Request, Reverse-path TLV in der Antwort und ACH beziehungsweise IP/UDP mit 127/8 zu protokollieren. Bei P2MP mit IP-Adressierung müssen die RFC-6425-Verfahren unterstützt werden; ohne IP-Adressierung gelten die Nicht-IP-Verfahren von RFC 6426.

Jede Antwort ist dem richtigen Zweig und der richtigen Identität zuzuordnen. Ein Knoten, der den angeforderten Reply-Modus nicht unterstützt oder nicht verwenden kann, muss die Anfrage verwerfen. RFC 6426 warnt vor ACH On-Demand-CV mit ECMP: Der ACH-Header kann das Hashing verändern, sodass ein anderer Pfad als der Datenpfad beobachtet wird.

RFC 4379 liefert die LSP-Ping-Grundverfahren, RFC 5586 die G-ACh-Trägerfunktion, RFC 5860 OAM-Anforderungen für MPLS-TP und RFC 5884 den BFD-Kontext für MPLS. RFC 5920 behandelt den Sicherheitsrahmen, RFC 5921 die Transportprofil-Architektur, RFC 6370 MPLS-TP-Identifier und RFC 6371 OAM-Rahmen sowie Autoritätsgrenzen. Diese unterstützenden Rollen ersetzen keine Validierung nach RFC 6426. Aus dem Material folgen weder Aussagen zu Herstelleradoption, Verbreitung, Vorfällen, Probe-Latenz oder -Verlust, kommerziellem Wert noch Kundenergebnissen.

Entscheidungsweg für Betreiber

  1. Statischen LSP- oder PW-FEC, erwartete Quelle, Zielidentität und Interface festlegen; IP/UDP oder ACH passend zum Pfad wählen.
  2. TTL und Reply-Modus bestimmen, R nur bei benötigter Reverse-FEC-Evidenz setzen und das Erfolgskriterium vor dem Versand definieren.
  3. Identität, TTL, Kapselung, Interface, Label Stack, Target FEC, DSMAP/DDMAP und gegebenenfalls Reverse-FEC-TLV prüfen.
  4. Einen TTL-Responder nur diesem Zwischenpunkt zuordnen. Fehlt der Rückweg, sind Verwerfen oder Schweigen möglich. Bei jeder fehlgeschlagenen Prüfung Antwort verwerfen und melden.

Quellen