Zum Hauptinhalt springen

RFC 4379 - 1. Introduction

1. Einleitung (Introduction)​

Dieses Dokument beschreibt einen einfachen und effizienten Mechanismus zur Erkennung von Fehlern in der Datenebene von Multiprotocol Label Switching (Multi-Protocol Label Switching, MPLS) Label Switched Paths (Label Switched Path, LSP). Das Dokument besteht aus zwei Teilen: den Informationen, die in einer MPLS "echo request" und "echo reply" übertragen werden, und den Mechanismen zum Transport der echo reply. Der erste Teil soll genügend Informationen bereitstellen, um den korrekten Betrieb der Datenebene zu prüfen, sowie einen Mechanismus, um die Datenebene gegen die Kontrollebene zu verifizieren und dadurch Fehler zu lokalisieren. Der zweite Teil schlägt zwei Methoden für zuverlässige Antwortkanäle für die echo request-Nachricht vor, um eine robustere Fehlerisolierung zu erreichen.

Eine wichtige Überlegung bei diesem Entwurf ist, dass MPLS echo requests denselben Datenpfad nehmen, den normale MPLS-Pakete durchlaufen würden. MPLS echo requests dienen in erster Linie der Validierung der Datenebene und in zweiter Linie der Verifikation der Datenebene gegen die Kontrollebene. Mechanismen zur Prüfung der Kontrollebene sind wertvoll, werden in diesem Dokument jedoch nicht behandelt.

Dieses Dokument macht besonderen Gebrauch vom Adressbereich 127/8. Dies ist eine Ausnahme vom in RFC 1122 [RFC1122] definierten Verhalten und aktualisiert diesen RFC. Die Motivation für diese Änderung und die Einzelheiten dieser Ausnahmeverwendung werden unten in Abschnitt 2.1 erörtert.

1.1. Konventionen (Conventions)​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [KEYWORDS] beschrieben zu interpretieren.

Der Begriff "Must Be Zero" (MBZ) wird in Objektbeschreibungen für reservierte Felder verwendet. Diese Felder MUST beim Senden auf Null gesetzt und beim Empfang ignoriert werden.

Die Terminologie für L2- und L3-Virtual Private Networks (Virtual Private Network, VPN) ist in [RFC4026] definiert.

Da sich dieses Dokument weit häufiger auf die MPLS Time to Live (TTL) bezieht als auf die IP TTL, haben die Autoren die Konvention gewählt, das unqualifizierte "TTL" für "MPLS TTL" und "IP TTL" für den TTL-Wert im IP-Header zu verwenden.

1.2. Aufbau dieses Dokuments (Structure of This Document)​

Der Hauptteil dieses Memos enthält vier Hauptabschnitte: Motivation, das Paketformat für MPLS echo request/reply, den LSP-Ping-Betrieb und einen zuverlässigen Rückweg. Lesern, die sich zum ersten Mal mit dem Thema befassen, wird empfohlen, die eigentlichen Paketformate zu überspringen und zuerst die Theorie des Betriebs (Theory of Operation) zu lesen; das Dokument ist so aufgebaut, um Vorwärtsverweise zu vermeiden.

1.3. Mitwirkende (Contributors)​

Die folgenden Personen haben wesentlich zu allen Aspekten dieses Dokuments beigetragen, und ein großer Teil des Materials stammt aus Debatten und Diskussionen innerhalb dieser Gruppe.

  • Ronald P. Bonica, Juniper Networks, Inc.
  • Dave Cooper, Global Crossing
  • Ping Pan, Hammerhead Systems
  • Nischal Sheth, Juniper Networks, Inc.
  • Sanjay Wadhwa, Juniper Networks, Inc.