Zum Hauptinhalt springen

RFC 5880 - Bidirektionale Weiterleitungserkennung (BFD)

  • Status: Proposed Standard
  • Veröffentlicht: Juni 2010
  • Stream: IETF
  • Errata: Keine Errata

Abstract​

Dieses Dokument beschreibt ein Protokoll zur Erkennung von Fehlern im bidirektionalen Pfad zwischen zwei Forwarding Engines, einschließlich Schnittstellen, Datenverbindungen und soweit möglich der Forwarding Engines selbst, mit potenziell sehr geringer Latenz. Es arbeitet unabhängig von Medien, Datenprotokollen und Routing-Protokollen.

Contents​

Status of This Memo​

Dies ist ein Internet Standards Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung genehmigt. Weitere Informationen zu Internet Standards sind in Abschnitt 2 von RFC 5741 verfügbar.

Informationen über den aktuellen Status dieses Dokuments, Errata und wie man Feedback dazu geben kann, sind unter http://www.rfc-editor.org/info/rfc5880 erhältlich.

Copyright (c) 2010 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (http://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments in Kraft sind. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Code-Komponenten, die aus diesem Dokument extrahiert werden, müssen den Text der Simplified BSD License enthalten, wie in Abschnitt 4.e der Trust Legal Provisions beschrieben, und werden ohne Garantie bereitgestellt, wie in der Simplified BSD License beschrieben.

6.7. Authentication (Authentifizierung)​

Ein optionaler Authentication Section KANN im BFD Control Packet vorhanden sein. In seiner generischen Form besteht der Zweck des Authentication Section darin, alle notwendigen Informationen zu tragen, basierend auf dem verwendeten Authentifizierungstyp, um dem empfangenden System zu ermöglichen, die Gültigkeit des empfangenen Pakets zu bestimmen. Der genaue Mechanismus hängt vom verwendeten Authentifizierungstyp ab, aber im Allgemeinen wird das übertragende System Informationen in den Authentication Section einfügen, die für die Gültigkeit des Pakets bürgen, und das empfangende System wird den Authentication Section untersuchen und entweder das Paket zur weiteren Verarbeitung akzeptieren oder es verwerfen.

Derselbe Authentifizierungstyp und alle Schlüssel oder anderen notwendigen Informationen müssen offensichtlich von den beiden Systemen verwendet werden. Die Aushandlung des Authentifizierungstyps, der Schlüsselaustausch usw. liegen alle außerhalb des Geltungsbereichs dieser Spezifikation und werden voraussichtlich durch Mittel außerhalb des Protokolls durchgeführt.

Beachten Sie, dass in den folgenden Unterabschnitten "ein Paket akzeptieren" nur bedeutet, dass das Paket die Authentifizierung bestanden hat; es kann tatsächlich aus anderen Gründen verworfen werden, wie in den allgemeinen Paketempfangsregeln in Abschnitt 6.8.6 beschrieben.

Implementierungen, die Authentifizierung unterstützen, MÜSSEN beide Arten der SHA1-Authentifizierung unterstützen. Andere Formen der Authentifizierung sind optional.

6.7.1. Enabling and Disabling Authentication (Aktivierung und Deaktivierung der Authentifizierung)​

Es kann wünschenswert sein, die Authentifizierung für eine Sitzung zu aktivieren oder zu deaktivieren, ohne den Sitzungszustand zu stören. Der genaue Mechanismus dafür liegt außerhalb des Geltungsbereichs dieser Spezifikation. Es ist jedoch nützlich, auf einige Probleme bei der Unterstützung dieses Mechanismus hinzuweisen.

In einer einfachen Implementierung wird eine BFD-Sitzung fehlschlagen, wenn die Authentifizierung entweder ein- oder ausgeschaltet wird, da die Paketakzeptanzregeln im Wesentlichen erfordern, dass die lokalen und entfernten Maschinen dies in einer mehr oder weniger synchronisierten Weise tun (innerhalb der Detection Time) - ein Paket mit Authentifizierung wird nur akzeptiert, wenn die Authentifizierung "in Verwendung" ist (und ebenso Pakete ohne Authentifizierung).

Ein möglicher Ansatz besteht darin, eine Implementierung so zu erstellen, dass die Authentifizierung konfiguriert ist, aber nicht als "in Verwendung" gilt, bis das erste Paket mit einem übereinstimmenden Authentication Section empfangen wird (was die notwendige Synchronisierung bereitstellt). Ebenso könnte die Authentifizierung als deaktiviert konfiguriert werden, aber dennoch als "in Verwendung" gelten, bis der Empfang des ersten Pakets ohne Authentication Section erfolgt.

Um Sicherheitsrisiken zu vermeiden, SOLLTEN Implementierungen, die diese Methode verwenden, nur zulassen, dass der Authentifizierungszustand höchstens einmal ohne irgendeine Form von Intervention geändert wird (sodass die Authentifizierung nicht wiederholt ein- und ausgeschaltet werden kann, nur basierend auf dem Empfang von BFD Control Packets von entfernten Systemen). Sofern es nicht erwünscht ist, die Authentifizierung zu aktivieren oder zu deaktivieren, SOLLTE eine Implementierung NICHT zulassen, dass sich der Authentifizierungszustand basierend auf dem Empfang von BFD Control Packets ändert.

6.7.2. Simple Password Authentication (Einfache Passwortauthentifizierung)​

Die einfachste (und schwächste) Form der Authentifizierung ist Simple Password Authentication. Bei dieser Authentifizierungsmethode werden ein oder mehrere Passwörter (mit entsprechenden Key IDs) in jedem System konfiguriert, und eines dieser Passwort/ID-Paare wird in jedem BFD Control Packet übertragen. Das empfangende System akzeptiert das Paket, wenn das Passwort und die Key ID mit einem der in diesem System konfigurierten Passwort/ID-Paare übereinstimmen.

Übertragung mit Simple Password Authentication​

Das aktuell ausgewählte Passwort und die Key ID für die Sitzung MÜSSEN im Authentication Section jedes ausgehenden BFD Control Packets gespeichert werden. Das Auth Type-Feld MUSS auf 1 (Simple Password) gesetzt werden. Das Auth Len-Feld MUSS auf die richtige Länge (4 bis 19 Bytes) gesetzt werden.

Das Passwort ist eine binäre Zeichenkette und MUSS zwischen 1 und 16 Bytes lang sein. Für die Interoperabilität MUSS die Verwaltungsschnittstelle, über die das Passwort konfiguriert wird, ASCII-Zeichenketten akzeptieren, und SOLLTE auch die Konfiguration beliebiger binärer Zeichenketten in Hexadezimalform ermöglichen. Andere Konfigurationsmethoden KÖNNEN unterstützt werden.

Empfang mit Simple Password Authentication​

Wenn das empfangene BFD Control Packet keinen Authentication Section enthält oder der Auth Type nicht 1 (Simple Password) ist, MUSS das empfangene Paket verworfen werden.

Wenn das Auth Key ID-Feld nicht mit der ID eines konfigurierten Passworts übereinstimmt, MUSS das empfangene Paket verworfen werden.

Wenn das Auth Len-Feld nicht gleich der Länge des durch die Key ID ausgewählten Passworts plus drei ist, MUSS das Paket verworfen werden.

Wenn das Password-Feld nicht mit dem durch die Key ID ausgewählten Passwort übereinstimmt, MUSS das Paket verworfen werden.

Andernfalls MUSS das Paket akzeptiert werden.

6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication (Keyed MD5 und Meticulous Keyed MD5-Authentifizierung)​

Die Keyed MD5 und Meticulous Keyed MD5-Authentifizierungsmechanismen sind sehr ähnlich zu denen, die in anderen Protokollen verwendet werden. Bei diesen Authentifizierungsmethoden werden ein oder mehrere geheime Schlüssel (mit entsprechenden Schlüssel-IDs) in jedem System konfiguriert. Einer der Schlüssel ist in einem MD5 [MD5]-Digest enthalten, der über das ausgehende BFD Control Packet berechnet wird, aber der Schlüssel selbst wird nicht im Paket übertragen. Um Replay-Angriffe zu vermeiden, wird auch eine Sequenznummer in jedem Paket übertragen. Bei Keyed MD5 wird die Sequenznummer gelegentlich inkrementiert. Bei Meticulous Keyed MD5 wird die Sequenznummer bei jedem Paket inkrementiert.

Das empfangende System akzeptiert das Paket, wenn die Schlüssel-ID mit einem der konfigurierten Schlüssel übereinstimmt, ein MD5-Digest einschließlich des ausgewählten Schlüssels mit dem im Paket übertragenen übereinstimmt und die Sequenznummer größer oder gleich der zuletzt empfangenen Sequenznummer ist (bei Keyed MD5) oder strikt größer als die zuletzt empfangene Sequenznummer ist (bei Meticulous Keyed MD5).

Übertragung mit Keyed MD5 und Meticulous Keyed MD5-Authentifizierung

Das Auth Type-Feld MUSS auf 2 (Keyed MD5) oder 3 (Meticulous Keyed MD5) gesetzt werden. Das Auth Len-Feld MUSS auf 24 gesetzt werden. Das Auth Key ID-Feld MUSS auf die ID des aktuellen Authentifizierungsschlüssels gesetzt werden. Das Sequence Number-Feld MUSS auf bfd.XmitAuthSeq gesetzt werden.

Der Authentifizierungsschlüsselwert ist eine binäre Zeichenkette von bis zu 16 Bytes und MUSS in das Auth Key/Digest-Feld eingefügt werden, bei Bedarf mit nachfolgenden Null-Bytes aufgefüllt. Zur Interoperabilität MUSS die Verwaltungsschnittstelle, über die der Schlüssel konfiguriert wird, ASCII-Zeichenketten akzeptieren und SOLLTE auch die Konfiguration jeder beliebigen binären Zeichenkette in hexadezimaler Form ermöglichen. Andere Konfigurationsmethoden KÖNNEN unterstützt werden.

Ein MD5-Digest MUSS über das gesamte BFD Control Packet berechnet werden. Der resultierende Digest MUSS vor der Übertragung im Auth Key/Digest-Feld gespeichert werden (wobei der geheime Schlüssel ersetzt wird, der NICHT im Paket übertragen werden DARF).

Bei Keyed MD5 KANN bfd.XmitAuthSeq in zirkulärer Weise inkrementiert werden (wenn als vorzeichenloser 32-Bit-Wert behandelt). bfd.XmitAuthSeq SOLLTE inkrementiert werden, wenn sich der Sitzungszustand ändert oder wenn das übertragene BFD Control Packet einen anderen Inhalt als das zuvor übertragene Paket trägt. Die Entscheidung, wann bfd.XmitAuthSeq inkrementiert werden soll, liegt außerhalb des Geltungsbereichs dieser Spezifikation. Siehe den Abschnitt mit dem Titel "Security Considerations" (Sicherheitsüberlegungen) unten für eine Diskussion.

Bei Meticulous Keyed MD5 MUSS bfd.XmitAuthSeq in zirkulärer Weise inkrementiert werden (wenn als vorzeichenloser 32-Bit-Wert behandelt).

Empfang mit Keyed MD5 und Meticulous Keyed MD5-Authentifizierung

Wenn das empfangene BFD Control Packet keinen Authentication Section enthält oder der Auth Type nicht korrekt ist (2 für Keyed MD5 oder 3 für Meticulous Keyed MD5), MUSS das empfangene Paket verworfen werden.

Wenn das Auth Key ID-Feld nicht mit der ID eines konfigurierten Authentifizierungsschlüssels übereinstimmt, MUSS das empfangene Paket verworfen werden.

Wenn das Auth Len-Feld nicht gleich 24 ist, MUSS das Paket verworfen werden.

Wenn bfd.AuthSeqKnown 1 ist, untersuchen Sie das Sequence Number-Feld. Bei Keyed MD5, wenn die Sequenznummer außerhalb des Bereichs von bfd.RcvAuthSeq bis bfd.RcvAuthSeq+(3Detect Mult) inklusive liegt (wenn als vorzeichenloser zirkulärer 32-Bit-Zahlenraum behandelt), MUSS das empfangene Paket verworfen werden. Bei Meticulous Keyed MD5, wenn die Sequenznummer außerhalb des Bereichs von bfd.RcvAuthSeq+1 bis bfd.RcvAuthSeq+(3Detect Mult) inklusive liegt (wenn als vorzeichenloser zirkulärer 32-Bit-Zahlenraum behandelt), MUSS das empfangene Paket verworfen werden.

Andernfalls (bfd.AuthSeqKnown ist 0) MUSS bfd.AuthSeqKnown auf 1 gesetzt werden, und bfd.RcvAuthSeq MUSS auf den Wert des empfangenen Sequence Number-Felds gesetzt werden.

Ersetzen Sie den Inhalt des Auth Key/Digest-Felds durch den durch das empfangene Auth Key ID-Feld ausgewählten Authentifizierungsschlüssel. Wenn der MD5-Digest des gesamten BFD Control Packets gleich dem empfangenen Wert des Auth Key/Digest-Felds ist, MUSS das empfangene Paket akzeptiert werden. Andernfalls (der Digest stimmt nicht mit dem Auth Key/Digest-Feld überein) MUSS das empfangene Paket verworfen werden.

6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication (Keyed SHA1 und Meticulous Keyed SHA1-Authentifizierung)​

Die Keyed SHA1 und Meticulous Keyed SHA1-Authentifizierungsmechanismen sind sehr ähnlich zu denen, die in anderen Protokollen verwendet werden. Bei diesen Authentifizierungsmethoden werden ein oder mehrere geheime Schlüssel (mit entsprechenden Schlüssel-IDs) in jedem System konfiguriert. Einer der Schlüssel ist in einem SHA1 [SHA1]-Hash enthalten, der über das ausgehende BFD Control Packet berechnet wird, aber der Schlüssel selbst wird nicht im Paket übertragen. Um Replay-Angriffe zu vermeiden, wird auch eine Sequenznummer in jedem Paket übertragen. Bei Keyed SHA1 wird die Sequenznummer gelegentlich inkrementiert. Bei Meticulous Keyed SHA1 wird die Sequenznummer bei jedem Paket inkrementiert.

Das empfangende System akzeptiert das Paket, wenn die Schlüssel-ID mit einem der konfigurierten Schlüssel übereinstimmt, ein SHA1-Hash einschließlich des ausgewählten Schlüssels mit dem im Paket übertragenen übereinstimmt und die Sequenznummer größer oder gleich der zuletzt empfangenen Sequenznummer ist (bei Keyed SHA1) oder strikt größer als die zuletzt empfangene Sequenznummer ist (bei Meticulous Keyed SHA1).

Übertragung mit Keyed SHA1 und Meticulous Keyed SHA1-Authentifizierung

Das Auth Type-Feld MUSS auf 4 (Keyed SHA1) oder 5 (Meticulous Keyed SHA1) gesetzt werden. Das Auth Len-Feld MUSS auf 28 gesetzt werden. Das Auth Key ID-Feld MUSS auf die ID des aktuellen Authentifizierungsschlüssels gesetzt werden. Das Sequence Number-Feld MUSS auf bfd.XmitAuthSeq gesetzt werden.

Der Authentifizierungsschlüsselwert ist eine binäre Zeichenkette von bis zu 20 Bytes und MUSS in das Auth Key/Hash-Feld eingefügt werden, bei Bedarf mit nachfolgenden Null-Bytes aufgefüllt. Zur Interoperabilität MUSS die Verwaltungsschnittstelle, über die der Schlüssel konfiguriert wird, ASCII-Zeichenketten akzeptieren und SOLLTE auch die Konfiguration jeder beliebigen binären Zeichenkette in hexadezimaler Form ermöglichen. Andere Konfigurationsmethoden KÖNNEN unterstützt werden.

Ein SHA1-Hash MUSS über das gesamte BFD Control Packet berechnet werden. Der resultierende Hash MUSS vor der Übertragung im Auth Key/Hash-Feld gespeichert werden (wobei der geheime Schlüssel ersetzt wird, der NICHT im Paket übertragen werden DARF).

Bei Keyed SHA1 KANN bfd.XmitAuthSeq in zirkulärer Weise inkrementiert werden (wenn als vorzeichenloser 32-Bit-Wert behandelt). bfd.XmitAuthSeq SOLLTE inkrementiert werden, wenn sich der Sitzungszustand ändert oder wenn das übertragene BFD Control Packet einen anderen Inhalt als das zuvor übertragene Paket trägt. Die Entscheidung, wann bfd.XmitAuthSeq inkrementiert werden soll, liegt außerhalb des Geltungsbereichs dieser Spezifikation. Siehe den Abschnitt mit dem Titel "Security Considerations" (Sicherheitsüberlegungen) unten für eine Diskussion.

Bei Meticulous Keyed SHA1 MUSS bfd.XmitAuthSeq in zirkulärer Weise inkrementiert werden (wenn als vorzeichenloser 32-Bit-Wert behandelt).

Empfang mit Keyed SHA1 und Meticulous Keyed SHA1-Authentifizierung

Wenn das empfangene BFD Control Packet keinen Authentication Section enthält oder der Auth Type nicht korrekt ist (4 für Keyed SHA1 oder 5 für Meticulous Keyed SHA1), MUSS das empfangene Paket verworfen werden.

Wenn das Auth Key ID-Feld nicht mit der ID eines konfigurierten Authentifizierungsschlüssels übereinstimmt, MUSS das empfangene Paket verworfen werden.

Wenn das Auth Len-Feld nicht gleich 28 ist, MUSS das Paket verworfen werden.

Wenn bfd.AuthSeqKnown 1 ist, untersuchen Sie das Sequence Number-Feld. Bei Keyed SHA1, wenn die Sequenznummer außerhalb des Bereichs von bfd.RcvAuthSeq bis bfd.RcvAuthSeq+(3Detect Mult) inklusive liegt (wenn als vorzeichenloser zirkulärer 32-Bit-Zahlenraum behandelt), MUSS das empfangene Paket verworfen werden. Bei Meticulous Keyed SHA1, wenn die Sequenznummer außerhalb des Bereichs von bfd.RcvAuthSeq+1 bis bfd.RcvAuthSeq+(3Detect Mult) inklusive liegt (wenn als vorzeichenloser zirkulärer 32-Bit-Zahlenraum behandelt), MUSS das empfangene Paket verworfen werden.

Andernfalls (bfd.AuthSeqKnown ist 0) MUSS bfd.AuthSeqKnown auf 1 gesetzt werden, bfd.RcvAuthSeq MUSS auf den Wert des empfangenen Sequence Number-Felds gesetzt werden, und das empfangene Paket MUSS akzeptiert werden.

Ersetzen Sie den Inhalt des Auth Key/Hash-Felds durch den durch das empfangene Auth Key ID-Feld ausgewählten Authentifizierungsschlüssel. Wenn der SHA1-Hash des gesamten BFD Control Packets gleich dem empfangenen Wert des Auth Key/Hash-Felds ist, MUSS das empfangene Paket akzeptiert werden. Andernfalls (der Hash stimmt nicht mit dem Auth Key/Hash-Feld überein) MUSS das empfangene Paket verworfen werden.

6.8. Functional Specifics (Funktionale Spezifikationen)​

Der folgende Abschnitt dieser Spezifikation ist normativ. Die Mittel, durch die diese Spezifikation erreicht wird, liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Wenn gesagt wird, dass ein System "die Echo-Funktion aktiv hat", bedeutet dies, dass das System BFD Echo Packets sendet, was impliziert, dass die Sitzung Up ist und das andere System seine Bereitschaft signalisiert hat, Echo-Pakete zurückzuschleifen.

Wenn gesagt wird, dass das lokale System "Demand Mode aktiv" hat, bedeutet dies, dass bfd.DemandMode 1 im lokalen System ist (siehe Abschnitt 6.8.1), die Sitzung Up ist und das entfernte System signalisiert, dass die Sitzung im Zustand Up ist.

Wenn gesagt wird, dass das entfernte System "Demand Mode aktiv" hat, bedeutet dies, dass bfd.RemoteDemandMode 1 ist (das entfernte System hat das Demand (D) Bit im zuletzt empfangenen BFD Control Packet gesetzt), die Sitzung Up ist und das entfernte System signalisiert, dass die Sitzung im Zustand Up ist.

6.8.2. Timer Negotiation (Timer-Aushandlung)​

Die Zeitwerte, die zur Bestimmung der BFD-Paketübertragungsintervalle und der Sitzungs-Detection Time verwendet werden, werden kontinuierlich ausgehandelt und können daher jederzeit geändert werden. Die Aushandlung und Zeitwerte sind in jeder Richtung für jede Sitzung unabhängig.

Jedes System meldet im BFD Control Packet, wie schnell es BFD-Pakete übertragen möchte, sowie wie schnell es bereit ist, sie zu empfangen. Dies ermöglicht es beiden Systemen, einseitig die maximale Paketrate (minimales Intervall) in beide Richtungen zu bestimmen.

Siehe Abschnitt 6.8.7 für die Details des Paketübertragungstimings und der Aushandlung.

6.8.3. Timer Manipulation (Timer-Manipulation)​

Die Zeitwerte, die zur Bestimmung der BFD-Paketübertragungsintervalle und der Sitzungs-Detection Time verwendet werden, können jederzeit geändert werden, ohne den Zustand der Sitzung zu beeinflussen. Wenn die Timer-Parameter aus irgendeinem Grund geändert werden, gelten die Anforderungen dieses Abschnitts.

Wenn entweder bfd.DesiredMinTxInterval geändert wird oder bfd.RequiredMinRxInterval geändert wird, MUSS eine Poll Sequence initiiert werden (siehe Abschnitt 6.5). Wenn das Timing so ist, dass ein System die Parameter ändern möchte, während es eine Poll Sequence empfängt, KÖNNEN die neuen Parameterwerte in Paketen mit gesetztem Final (F) Bit übertragen werden, auch wenn die Poll Sequence noch nicht gesendet wurde.

Wenn bfd.DesiredMinTxInterval erhöht wird und bfd.SessionState Up ist, DARF sich das tatsächlich verwendete Übertragungsintervall NICHT ändern, bis die oben beschriebene Poll Sequence beendet wurde. Dies soll sicherstellen, dass das entfernte System seine Detection Time aktualisiert, bevor das Übertragungsintervall zunimmt.

Wenn bfd.RequiredMinRxInterval reduziert wird und bfd.SessionState Up ist, MUSS der vorherige Wert von bfd.RequiredMinRxInterval bei der Berechnung der Detection Time für das entfernte System verwendet werden, bis die oben beschriebene Poll Sequence beendet wurde. Dies soll sicherstellen, dass das entfernte System Pakete mit der höheren Rate überträgt (und diese Pakete empfangen werden), bevor die Detection Time reduziert wird.

Wenn bfd.SessionState nicht Up ist, MUSS das System bfd.DesiredMinTxInterval auf einen Wert von nicht weniger als einer Sekunde (1.000.000 Mikrosekunden) setzen. Dies soll sicherstellen, dass die von BFD-Sitzungen verbrauchte Bandbreite, die nicht Up sind, vernachlässigbar ist, insbesondere in dem Fall, dass ein Nachbar möglicherweise nicht BFD ausführt.

Wenn das lokale System sein Übertragungsintervall aufgrund der Reduzierung von bfd.RemoteMinRxInterval reduziert (das entfernte System hat einen reduzierten Wert in Required Min RX Interval angekündigt), und das entfernte System sich nicht im Demand Mode befindet, MUSS das lokale System das neue Intervall sofort einhalten. Mit anderen Worten, das lokale System kann nicht länger als das neue Intervall zwischen der vorherigen Paketübertragung und der nächsten warten. Wenn dieses Intervall seit der letzten Übertragung bereits verstrichen ist (weil das neue Intervall erheblich kürzer ist), MUSS das lokale System das nächste periodische BFD Control Packet so bald wie praktikabel senden.

Wenn die Echo-Funktion aktiv ist, SOLLTE ein System bfd.RequiredMinRxInterval auf einen Wert von nicht weniger als einer Sekunde (1.000.000 Mikrosekunden) setzen. Dies soll den empfangenen BFD Control Traffic auf einem vernachlässigbaren Niveau halten, da die tatsächliche Erkennungsfunktion mit BFD Echo Packets durchgeführt wird.

In jedem anderen Fall als den oben explizit genannten MÜSSEN Änderungen der Timing-Parameter sofort wirksam werden (Änderung der Übertragungsrate und/oder der Detection Time).

Beachten Sie, dass der Poll Sequence-Mechanismus mehrdeutig ist, wenn mehr als eine Parameteränderung vorgenommen wird, die seine Verwendung erfordern würde, und diese mehreren Änderungen über mehrere Pakete verteilt sind (da die Semantik des zurückkehrenden Final unklar ist). Daher gibt es, wenn mehrere Änderungen vorgenommen werden, die die Verwendung einer Poll Sequence erfordern, drei Möglichkeiten: 1) sie MÜSSEN in einem einzigen BFD Control Packet kommuniziert werden (damit die Semantik der Final-Antwort klar ist), oder 2) ausreichend Zeit muss seit dem Abschluss der Poll Sequence verstrichen sein, um die Situation zu disambiguieren (mindestens eine Round-Trip-Zeit seit der Übertragung des letzten Poll), bevor eine weitere Poll Sequence initiiert wird, oder 3) ein zusätzliches BFD Control Packet mit gelöschtem Final (F) Bit MUSS nach Abschluss der Poll Sequence empfangen werden, bevor eine weitere Poll Sequence initiiert wird (diese Option ist nicht verfügbar, wenn Demand Mode aktiv ist).

6.8.4. Calculating the Detection Time (Berechnung der Erkennungszeit)​

Die Detection Time (die Zeitperiode ohne Empfang von BFD-Paketen, nach der die Sitzung als ausgefallen bestimmt wird) wird nicht explizit im Protokoll übertragen. Vielmehr wird sie unabhängig in jeder Richtung vom empfangenden System basierend auf dem ausgehandelten Übertragungsintervall und dem Erkennungsmultiplikator berechnet. Beachten Sie, dass es in jeder Richtung unterschiedliche Detection Times geben kann.

Die Berechnung der Detection Time unterscheidet sich leicht zwischen Demand Mode und Asynchronous Mode.

Im Asynchronous Mode ist die im lokalen System berechnete Detection Time gleich dem Wert von Detect Mult, der vom entfernten System empfangen wurde, multipliziert mit dem vereinbarten Übertragungsintervall des entfernten Systems (dem größeren Wert von bfd.RequiredMinRxInterval und dem zuletzt empfangenen Desired Min TX Interval). Der Detect Mult-Wert ist (grob gesagt, aufgrund von Jitter) die Anzahl der Pakete, die hintereinander verpasst werden müssen, um die Sitzung als ausgefallen zu erklären.

Wenn der Demand Mode nicht aktiv ist und eine Zeitperiode gleich der Detection Time vergeht, ohne ein BFD Control Packet vom entfernten System zu empfangen, und bfd.SessionState Init oder Up ist, ist die Sitzung ausgefallen - das lokale System MUSS bfd.SessionState auf Down und bfd.LocalDiag auf 1 (Control Detection Time Expired) setzen.

Im Demand Mode ist die im lokalen System berechnete Detection Time gleich bfd.DetectMult, multipliziert mit dem vereinbarten Übertragungsintervall des lokalen Systems (dem größeren Wert von bfd.DesiredMinTxInterval und bfd.RemoteMinRxInterval). bfd.DetectMult ist (grob gesagt, aufgrund von Jitter) die Anzahl der Pakete, die hintereinander verpasst werden müssen, um die Sitzung als ausgefallen zu erklären.

Wenn der Demand Mode aktiv ist und eine Zeitperiode gleich der Detection Time nach der Initiierung einer Poll Sequence (der Übertragung des ersten BFD Control Packets mit gesetztem Poll-Bit) vergeht, ist die Sitzung ausgefallen - das lokale System MUSS bfd.SessionState auf Down und bfd.LocalDiag auf 1 (Control Detection Time Expired) setzen.

(Beachten Sie, dass ein Paket als empfangen betrachtet wird, für die Zwecke des Ablaufs der Detection Time, nur wenn es nicht gemäß den Regeln von Abschnitt 6.8.6 "verworfen" wurde).

6.8.5. Detecting Failures with the Echo Function (Fehlererkennung mit der Echo-Funktion)​

Wenn die Echo-Funktion aktiv ist und eine ausreichende Anzahl von Echo-Paketen nicht wie erwartet angekommen ist, ist die Sitzung ausgefallen - das lokale System MUSS bfd.SessionState auf Down und bfd.LocalDiag auf 2 (Echo Function Failed) setzen.

Die Mittel, mit denen Echo-Funktionsfehler erkannt werden, liegen außerhalb des Geltungsbereichs dieser Spezifikation. Jedes Mittel, das einen Kommunikationsfehler erkennt, ist akzeptabel.

6.8.6. Reception of BFD Control Packets (Empfang von BFD Control Packets)​

Wenn ein BFD Control Packet empfangen wird, MUSS das folgende Verfahren in der angegebenen Reihenfolge befolgt werden. Wenn das Paket gemäß diesen Regeln verworfen wird, MUSS die Verarbeitung des Pakets an diesem Punkt beendet werden.

  • Wenn die Versionsnummer nicht korrekt ist (1), MUSS das Paket verworfen werden.
  • Wenn das Length-Feld kleiner als der minimale korrekte Wert ist (24, wenn das A-Bit gelöscht ist, oder 26, wenn das A-Bit gesetzt ist), MUSS das Paket verworfen werden.
  • Wenn das Length-Feld größer als die Nutzdaten des verkapselenden Protokolls ist, MUSS das Paket verworfen werden.
  • Wenn das Detect Mult-Feld null ist, MUSS das Paket verworfen werden.
  • Wenn das Multipoint (M) Bit ungleich Null ist, MUSS das Paket verworfen werden.
  • Wenn das My Discriminator-Feld null ist, MUSS das Paket verworfen werden.
  • Wenn das Your Discriminator-Feld ungleich Null ist, MUSS es verwendet werden, um die Sitzung auszuwählen, mit der dieses BFD-Paket assoziiert ist. Wenn keine Sitzung gefunden wird, MUSS das Paket verworfen werden.
  • Wenn das Your Discriminator-Feld null ist und das State-Feld nicht Down oder AdminDown ist, MUSS das Paket verworfen werden.
  • Wenn das Your Discriminator-Feld null ist, MUSS die Sitzung basierend auf einer Kombination anderer Felder ausgewählt werden, möglicherweise einschließlich Quelladressierungsinformationen, des My Discriminator-Felds und der Schnittstelle, über die das Paket empfangen wurde. Die genaue Auswahlmethode ist anwendungsspezifisch und liegt somit außerhalb des Geltungsbereichs dieser Spezifikation. Wenn keine passende Sitzung gefunden wird, KANN eine neue Sitzung erstellt werden, oder das Paket KANN verworfen werden. Diese Wahl liegt außerhalb des Geltungsbereichs dieser Spezifikation.
  • Wenn das A-Bit gesetzt ist und keine Authentifizierung verwendet wird (bfd.AuthType ist null), MUSS das Paket verworfen werden.
  • Wenn das A-Bit gelöscht ist und Authentifizierung verwendet wird (bfd.AuthType ist ungleich Null), MUSS das Paket verworfen werden.
  • Wenn das A-Bit gesetzt ist, MUSS das Paket gemäß den Regeln von Abschnitt 6.7 authentifiziert werden, basierend auf dem verwendeten Authentifizierungstyp (bfd.AuthType). Dies kann dazu führen, dass das Paket verworfen wird.
  • Setzen Sie bfd.RemoteDiscr auf den Wert von My Discriminator.
  • Setzen Sie bfd.RemoteState auf den Wert des State (Sta) Felds.
  • Setzen Sie bfd.RemoteDemandMode auf den Wert des Demand (D) Bits.
  • Setzen Sie bfd.RemoteMinRxInterval auf den Wert von Required Min RX Interval.
  • Wenn das Required Min Echo RX Interval-Feld null ist, MUSS die Übertragung von Echo-Paketen, falls vorhanden, beendet werden.
  • Wenn eine Poll Sequence vom lokalen System übertragen wird und das Final (F) Bit im empfangenen Paket gesetzt ist, MUSS die Poll Sequence beendet werden.
  • Aktualisieren Sie das Übertragungsintervall wie in Abschnitt 6.8.2 beschrieben.
  • Aktualisieren Sie die Detection Time wie in Abschnitt 6.8.4 beschrieben.

Zustandsmaschinenverarbeitung:

Wenn bfd.SessionState AdminDown ist:

  • Verwerfen Sie das Paket

Wenn empfangener Zustand AdminDown ist:

  • Wenn bfd.SessionState nicht Down ist:
    • Setzen Sie bfd.LocalDiag auf 3 (Neighbor signaled session down)
    • Setzen Sie bfd.SessionState auf Down

Sonst:

  • Wenn bfd.SessionState Down ist:
    • Wenn empfangener State Down ist:
      • Setzen Sie bfd.SessionState auf Init
    • Sonst wenn empfangener State Init ist:
      • Setzen Sie bfd.SessionState auf Up
  • Sonst wenn bfd.SessionState Init ist:
    • Wenn empfangener State Init oder Up ist:
      • Setzen Sie bfd.SessionState auf Up
  • Sonst (bfd.SessionState ist Up):
    • Wenn empfangener State Down ist:
      • Setzen Sie bfd.LocalDiag auf 3 (Neighbor signaled session down)
      • Setzen Sie bfd.SessionState auf Down

Überprüfen Sie, ob Demand Mode aktiv werden sollte oder nicht (siehe Abschnitt 6.6).

Wenn bfd.RemoteDemandMode 1 ist, bfd.SessionState Up ist und bfd.RemoteSessionState Up ist, ist Demand Mode auf dem entfernten System aktiv und das lokale System MUSS die periodische Übertragung von BFD Control Packets beenden (siehe Abschnitt 6.8.7).

Wenn bfd.RemoteDemandMode 0 ist, oder bfd.SessionState nicht Up ist, oder bfd.RemoteSessionState nicht Up ist, ist Demand Mode auf dem entfernten System nicht aktiv und das lokale System MUSS periodische BFD Control Packets senden (siehe Abschnitt 6.8.7).

Wenn das Poll (P) Bit gesetzt ist, senden Sie ein BFD Control Packet an das entfernte System mit gelöschtem Poll (P) Bit und gesetztem Final (F) Bit (siehe Abschnitt 6.8.7).

Wenn das Paket nicht verworfen wurde, wurde es für die Zwecke der Detection Time-Ablaufregeln in Abschnitt 6.8.4 empfangen.

6.8.7. Transmitting BFD Control Packets (Senden von BFD Control Packets)​

Mit Ausnahme der im Rest dieses Abschnitts aufgeführten Fälle DARF ein System BFD Control Packets NICHT mit einem Intervall übertragen, das kleiner ist als das größere von bfd.DesiredMinTxInterval und bfd.RemoteMinRxInterval, abzüglich angewendetem Jitter (siehe unten). Mit anderen Worten, das System, das die langsamere Rate meldet, bestimmt die Übertragungsrate.

Die periodische Übertragung von BFD Control Packets MUSS paketweise um bis zu 25% geglättert werden, d.h. das Intervall MUSS um einen Zufallswert von 0 bis 25% reduziert werden, um eine Selbstsynchronisation mit anderen Systemen im selben Subnetz zu vermeiden. Somit wird das durchschnittliche Intervall zwischen Paketen etwa 12,5% geringer sein als das ausgehandelte.

Wenn bfd.DetectMult gleich 1 ist, MUSS das Intervall zwischen übertragenen BFD Control Packets nicht mehr als 90% des ausgehandelten Übertragungsintervalls und MUSS nicht weniger als 75% des ausgehandelten Übertragungsintervalls betragen. Dies soll sicherstellen, dass auf dem entfernten System die berechnete Detection Time nicht vor dem Empfang des nächsten BFD Control Packets abläuft.

Das Übertragungsintervall MUSS neu berechnet werden, wann immer bfd.DesiredMinTxInterval sich ändert oder wann immer bfd.RemoteMinRxInterval sich ändert, und ist gleich dem größeren dieser beiden Werte. Siehe Abschnitte 6.8.2 und 6.8.3 für Details zu Übertragungstimern.

Ein System DARF NICHT BFD Control Packets übertragen, wenn bfd.RemoteDiscr null ist und das System die Passive Role übernimmt.

Ein System DARF NICHT periodisch BFD Control Packets übertragen, wenn bfd.RemoteMinRxInterval null ist.

Ein System DARF NICHT periodisch BFD Control Packets übertragen, wenn Demand Mode auf dem entfernten System aktiv ist (bfd.RemoteDemandMode ist 1, bfd.SessionState ist Up und bfd.RemoteSessionState ist Up) und keine Poll Sequence übertragen wird.

Wenn ein BFD Control Packet mit gesetztem Poll (P) Bit empfangen wird, MUSS das empfangende System ein BFD Control Packet mit gelöschtem Poll (P) Bit und gesetztem Final (F) Bit so bald wie praktikabel übertragen, ohne Rücksicht auf den Übertragungstimer oder andere Übertragungsbeschränkungen, ohne Rücksicht auf den Sitzungszustand und ohne Rücksicht darauf, ob Demand Mode auf beiden Systemen aktiv ist. Ein System KANN die Rate begrenzen, mit der solche Pakete übertragen werden. Wenn eine Ratenbegrenzung aktiv ist, MUSS der angekündigte Wert von Desired Min TX Interval größer oder gleich dem Intervall zwischen übertragenen Paketen sein, das durch die Ratenbegrenzungsfunktion auferlegt wird.

Ein System DARF NICHT das Demand (D) Bit setzen, es sei denn, bfd.DemandMode ist 1, bfd.SessionState ist Up und bfd.RemoteSessionState ist Up.

Ein BFD Control Packet SOLLTE während des Intervalls zwischen periodischen Control Packet-Übertragungen übertragen werden, wenn der Inhalt dieses Pakets sich von dem im zuvor übertragenen Paket unterscheiden würde (außer den Poll- und Final-Bits), um eine Zustandsänderung schneller zu kommunizieren.

Inhalt übertragener BFD Control Packets​

Der Inhalt übertragener BFD Control Packets MUSS wie folgt gesetzt werden:

Version: Auf die aktuelle Versionsnummer (1) gesetzt.

Diagnostic (Diag): Auf bfd.LocalDiag gesetzt.

State (Sta): Auf den durch bfd.SessionState angegebenen Wert gesetzt.

Poll (P): Auf 1 gesetzt, wenn das lokale System eine Poll Sequence sendet, oder 0, wenn nicht.

Final (F): Auf 1 gesetzt, wenn das lokale System auf ein empfangenes Control Packet mit gesetztem Poll (P) Bit antwortet, oder 0, wenn nicht.

Control Plane Independent (C): Auf 1 gesetzt, wenn die BFD-Implementierung des lokalen Systems unabhängig von der Control Plane ist (sie kann durch eine Störung der Control Plane weiter funktionieren).

Authentication Present (A): Auf 1 gesetzt, wenn Authentifizierung in dieser Sitzung verwendet wird (bfd.AuthType ist ungleich Null), oder 0, wenn nicht.

Demand (D): Auf bfd.DemandMode gesetzt, wenn bfd.SessionState Up ist und bfd.RemoteSessionState Up ist. Andernfalls auf 0 gesetzt.

Multipoint (M): Auf 0 gesetzt.

Detect Mult: Auf bfd.DetectMult gesetzt.

Length: Auf die entsprechende Länge gesetzt, basierend auf der festen Header-Länge (24) plus eventuellem Authentication Section.

My Discriminator: Auf bfd.LocalDiscr gesetzt.

Your Discriminator: Auf bfd.RemoteDiscr gesetzt.

Desired Min TX Interval: Auf bfd.DesiredMinTxInterval gesetzt.

Required Min RX Interval: Auf bfd.RequiredMinRxInterval gesetzt.

Required Min Echo RX Interval: Auf das minimale erforderliche Echo-Paketempfangsintervall für diese Sitzung gesetzt. Wenn dieses Feld auf Null gesetzt ist, ist das lokale System nicht bereit oder nicht in der Lage, BFD Echo-Pakete an das entfernte System zurückzuschleifen, und das entfernte System wird keine Echo-Pakete senden.

Authentication Section: Enthalten und gemäß den Regeln in Abschnitt 6.7 gesetzt, wenn Authentifizierung verwendet wird (bfd.AuthType ist ungleich Null). Andernfalls ist dieser Abschnitt nicht vorhanden.

6.8.8. Reception of BFD Echo Packets (Empfang von BFD-Echo-Paketen)​

Ein empfangenes BFD Echo Packet MUSS zur entsprechenden Sitzung zur Verarbeitung demultiplext werden. Ein Mittel zur Erkennung fehlender Echo-Pakete MUSS implementiert werden, was höchstwahrscheinlich die Verarbeitung der empfangenen Echo-Pakete beinhaltet. Die Verarbeitung empfangener Echo-Pakete liegt ansonsten außerhalb des Geltungsbereichs dieser Spezifikation.

6.8.9. Transmission of BFD Echo Packets (Übertragung von BFD-Echo-Paketen)​

BFD Echo Packets DÜRFEN NICHT übertragen werden, wenn bfd.SessionState nicht Up ist. BFD Echo Packets DÜRFEN NICHT übertragen werden, es sei denn, das letzte vom entfernten System empfangene BFD Control Packet enthält einen von Null verschiedenen Wert in Required Min Echo RX Interval.

BFD Echo Packets KÖNNEN übertragen werden, wenn bfd.SessionState Up ist. Das Intervall zwischen übertragenen BFD Echo Packets DARF NICHT kleiner sein als der vom entfernten System in Required Min Echo RX Interval angekündigte Wert, außer wie folgt:

Ein 25%-Jitter KANN auf die Übertragungsrate angewendet werden, so dass das tatsächliche Intervall zwischen 75% und 100% des angekündigten Werts liegen KANN. Ein einzelnes BFD Echo Packet KANN zwischen normalerweise geplanten Echo-Übertragungsintervallen übertragen werden.

Die Übertragung von BFD Echo Packets liegt ansonsten außerhalb des Geltungsbereichs dieser Spezifikation.