Zum Hauptinhalt springen

9. UPDATE Message Handling (UPDATE-Nachrichtenverarbeitung)

  1. UPDATE Message Handling (UPDATE-Nachrichtenverarbeitung)

    Eine UPDATE-Nachricht kann nur im Established-Zustand empfangen werden. Das Empfangen einer UPDATE-Nachricht in einem anderen Zustand ist ein Fehler. Wenn eine UPDATE-Nachricht empfangen wird, wird jedes Feld auf Gültigkeit überprüft, wie in Abschnitt 6.3 angegeben.

    Wenn ein optionales nicht-transitives Attribut nicht erkannt wird, wird es stillschweigend ignoriert. Wenn ein optionales transitives Attribut nicht erkannt wird, wird das Partial-Bit (das dritte höchstwertige Bit) im Attribut-Flags-Oktett auf 1 gesetzt, und das Attribut wird zur Weitergabe an andere BGP-Speaker beibehalten.

    Wenn ein optionales Attribut erkannt wird und einen gültigen Wert hat, wird es je nach Typ des optionalen Attributs lokal verarbeitet, beibehalten und bei Bedarf aktualisiert, um möglicherweise an andere BGP-Speaker weitergegeben zu werden.

    Wenn die UPDATE-Nachricht ein nicht-leeres WITHDRAWN ROUTES-Feld enthält, müssen (SHALL) die zuvor angekündigten Routen, deren Ziele (ausgedrückt als IP-Präfixe) in diesem Feld enthalten sind, aus dem Adj-RIB-In entfernt werden. Dieser BGP-Speaker muss (SHALL) seinen Entscheidungsprozess ausführen, da die zuvor angekündigte Route nicht mehr zur Verfügung steht.

    Wenn die UPDATE-Nachricht eine machbare Route enthält, wird das Adj-RIB-In wie folgt mit dieser Route aktualisiert: Wenn das NLRI der neuen Route mit dem identisch ist, das die Route derzeit im Adj-RIB-In gespeichert hat, muss (SHALL) die neue Route die ältere Route im Adj-RIB-In ersetzen und damit die ältere Route implizit aus dem Dienst zurückziehen. Andernfalls, wenn das Adj-RIB-In keine Route mit einem NLRI hat, das mit der neuen Route identisch ist, muss (SHALL) die neue Route im Adj-RIB-In platziert werden.

    Sobald der BGP-Speaker das Adj-RIB-In aktualisiert, muss (SHALL) der Speaker seinen Entscheidungsprozess ausführen.

9.1. Decision Process (Entscheidungsprozess)

Der Entscheidungsprozess wählt Routen für die nachfolgende Ankündigung aus, indem er die Richtlinien in der lokalen Policy Information Base (PIB) auf die in seinen Adj-RIBs-In gespeicherten Routen anwendet. Die Ausgabe des Entscheidungsprozesses ist die Menge der Routen, die an Peers angekündigt werden; die ausgewählten Routen werden gemäß der Richtlinie in den Adj-RIBs-Out des lokalen Speakers gespeichert.

Der hier beschriebene BGP-Entscheidungsprozess ist konzeptionell und muss nicht genau wie beschrieben implementiert werden, solange die Implementierungen die beschriebene Funktionalität unterstützen und das gleiche extern sichtbare Verhalten zeigen.

Der Auswahlprozess wird formalisiert, indem eine Funktion definiert wird, die das Attribut einer gegebenen Route als Argument nimmt und entweder (a) eine nicht-negative Ganzzahl zurückgibt, die den Grad der Präferenz für die Route angibt, oder (b) einen Wert zurückgibt, der angibt, dass diese Route nicht berechtigt ist, in Loc-RIB installiert zu werden und von der nächsten Phase der Routenauswahl ausgeschlossen wird.

Die Funktion, die den Grad der Präferenz für eine gegebene Route berechnet, darf (SHALL NOT) keines der folgenden als Eingaben verwenden: die Existenz anderer Routen, die Nicht-Existenz anderer Routen oder die Pfadattribute anderer Routen. Die Routenauswahl besteht dann aus der individuellen Anwendung der Präferenzgradfunktion auf jede machbare Route, gefolgt von der Wahl derjenigen mit dem höchsten Grad der Präferenz.

Der Entscheidungsprozess arbeitet mit Routen, die in den Adj-RIBs-In enthalten sind, und ist verantwortlich für:

  • Auswahl von Routen, die lokal vom Speaker verwendet werden sollen

  • Auswahl von Routen, die an andere BGP-Peers angekündigt werden sollen

  • Routenaggregation und Routeninformationsreduktion

Der Entscheidungsprozess findet in drei verschiedenen Phasen statt, die jeweils durch ein anderes Ereignis ausgelöst werden:

a) Phase 1 ist für die Berechnung des Präferenzgrades für jede von einem Peer empfangene Route verantwortlich.

b) Phase 2 wird bei Abschluss von Phase 1 aufgerufen. Sie ist für die Auswahl der besten Route aus allen verfügbaren für jedes eindeutige Ziel und für die Installation jeder gewählten Route im Loc-RIB verantwortlich.

c) Phase 3 wird aufgerufen, nachdem das Loc-RIB geändert wurde. Sie ist für die Verbreitung von Routen im Loc-RIB an jeden Peer gemäß den in der PIB enthaltenen Richtlinien verantwortlich. Routenaggregation und Informationsreduktion können optional in dieser Phase durchgeführt werden.

9.1.1. Phase 1: Calculation of Degree of Preference (Phase 1: Berechnung des Präferenzgrades)

Die Phase-1-Entscheidungsfunktion wird aufgerufen, wenn der lokale BGP-Speaker von einem Peer eine UPDATE-Nachricht empfängt, die eine neue Route, eine Ersatzroute oder zurückgezogene Routen ankündigt.

Die Phase-1-Entscheidungsfunktion ist ein separater Prozess, der abgeschlossen wird, wenn keine weitere Arbeit mehr zu erledigen ist.

Die Phase-1-Entscheidungsfunktion sperrt ein Adj-RIB-In, bevor sie auf eine darin enthaltene Route operiert, und entsperrt es, nachdem sie auf alle neuen oder nicht machbaren Routen darin operiert hat.

Für jede neu empfangene oder ersetzende machbare Route bestimmt der lokale BGP-Speaker einen Präferenzgrad wie folgt:

Wenn die Route von einem internen Peer gelernt wird, wird entweder der Wert des LOCAL_PREF-Attributs als Präferenzgrad genommen, oder das lokale System berechnet den Präferenzgrad der Route basierend auf vorkonfigurierten Richtlinieninformationen. Beachten Sie, dass Letzteres zur Bildung persistenter Routing-Schleifen führen kann.

Wenn die Route von einem externen Peer gelernt wird, berechnet der lokale BGP-Speaker den Präferenzgrad basierend auf vorkonfigurierten Richtlinieninformationen. Wenn der Rückgabewert anzeigt, dass die Route nicht berechtigt ist, darf (MAY NOT) die Route nicht als Eingabe für die nächste Phase der Routenauswahl dienen; andernfalls muss (MUST) der Rückgabewert als LOCAL_PREF-Wert in jeder IBGP-Neuankündigung verwendet werden.

Die genaue Natur dieser Richtlinieninformationen und die damit verbundene Berechnung ist eine lokale Angelegenheit.

9.1.2. Phase 2: Route Selection (Phase 2: Routenauswahl)

Die Phase-2-Entscheidungsfunktion wird bei Abschluss von Phase 1 aufgerufen. Die Phase-2-Funktion ist ein separater Prozess, der abgeschlossen wird, wenn keine weitere Arbeit mehr zu erledigen ist. Der Phase-2-Prozess berücksichtigt alle Routen, die in den Adj-RIBs-In berechtigt sind.

Die Phase-2-Entscheidungsfunktion wird blockiert, während die Phase-3-Entscheidungsfunktion läuft. Die Phase-2-Funktion sperrt alle Adj-RIBs-In, bevor sie ihre Funktion beginnt, und entsperrt sie bei Abschluss.

Wenn das NEXT_HOP-Attribut einer BGP-Route eine Adresse darstellt, die nicht auflösbar ist, oder wenn sie unauflösbar würde, wenn die Route in der Routing-Tabelle installiert würde, muss (MUST) die BGP-Route von der Phase-2-Entscheidungsfunktion ausgeschlossen werden.

Wenn das AS_PATH-Attribut einer BGP-Route eine AS-Schleife enthält, sollte (SHOULD) die BGP-Route von der Phase-2-Entscheidungsfunktion ausgeschlossen werden. Die AS-Schleifenerkennung erfolgt durch Scannen des vollständigen AS-Pfads (wie im AS_PATH-Attribut angegeben) und Überprüfung, dass die autonome Systemnummer des lokalen Systems nicht im AS-Pfad erscheint. Operationen eines BGP-Speakers, der konfiguriert ist, Routen mit seiner eigenen autonomen Systemnummer im AS-Pfad zu akzeptieren, liegen außerhalb des Geltungsbereichs dieses Dokuments.

Es ist kritisch, dass BGP-Speaker innerhalb eines AS keine widersprüchlichen Entscheidungen bezüglich der Routenauswahl treffen, die Weiterleitungsschleifen verursachen würden.

Für jede Menge von Zielen, für die eine machbare Route in den Adj-RIBs-In existiert, identifiziert der lokale BGP-Speaker die Route, die:

a) den höchsten Präferenzgrad aller Routen zur gleichen Menge von Zielen hat, oder

b) die einzige Route zu diesem Ziel ist, oder

c) als Ergebnis der in Abschnitt 9.1.2.2 spezifizierten Phase-2-Tie-Breaking-Regeln ausgewählt wird.

Der lokale Speaker muss (SHALL) dann diese Route im Loc-RIB installieren und jede Route zum gleichen Ziel ersetzen, die derzeit im Loc-RIB gehalten wird. Wenn die neue BGP-Route in der Routing-Tabelle installiert wird, muss darauf geachtet werden, dass vorhandene Routen zum gleichen Ziel, die jetzt als ungültig betrachtet werden, aus der Routing-Tabelle entfernt werden. Ob die neue BGP-Route eine vorhandene Nicht-BGP-Route in der Routing-Tabelle ersetzt, hängt von der auf dem BGP-Speaker konfigurierten Richtlinie ab.

Der lokale Speaker muss (MUST) die unmittelbare Next-Hop-Adresse aus dem NEXT_HOP-Attribut der ausgewählten Route bestimmen (siehe Abschnitt 5.1.3). Wenn sich entweder der unmittelbare Next-Hop oder die IGP-Kosten zum NEXT_HOP (wo der NEXT_HOP über eine IGP-Route aufgelöst wird) ändern, muss (MUST) die Phase-2-Routenauswahl erneut durchgeführt werden.

Beachten Sie, dass BGP-Routen zwar nicht mit dem/den unmittelbaren Next-Hop(s) in der Routing-Tabelle installiert werden müssen, Implementierungen jedoch darauf achten müssen (MUST), dass die zugehörige NEXT_HOP-Adresse in die unmittelbare (direkt verbundene) Next-Hop-Adresse aufgelöst wird, bevor Pakete entlang einer BGP-Route weitergeleitet werden, und dass diese Adresse (oder mehrere Adressen) schließlich für die tatsächliche Paketweiterleitung verwendet wird.

Nicht auflösbare Routen müssen (SHALL) aus dem Loc-RIB und der Routing-Tabelle entfernt werden. Entsprechende nicht auflösbare Routen sollten (SHOULD) jedoch in den Adj-RIBs-In aufbewahrt werden (falls sie auflösbar werden).

9.1.2.1. Route Resolvability Condition (Routenauflösbarkeitsbedingung)

Wie in Abschnitt 9.1.2 angegeben, sollten (SHOULD) BGP-Speaker nicht auflösbare Routen von der Phase-2-Entscheidung ausschließen. Dies stellt sicher, dass nur gültige Routen in Loc-RIB und der Routing-Tabelle installiert werden.

Die Routenauflösbarkeitsbedingung ist wie folgt definiert:

  1. Eine Route Rte1, die nur die Zwischennetzwerkadresse referenziert, gilt als auflösbar, wenn die Routing-Tabelle mindestens eine auflösbare Route Rte2 enthält, die mit der Zwischennetzwerkadresse von Rte1 übereinstimmt und nicht rekursiv (direkt oder indirekt) über Rte1 aufgelöst wird. Wenn mehrere übereinstimmende Routen verfügbar sind, sollte (SHOULD) nur die längste übereinstimmende Route berücksichtigt werden.

  2. Routen, die Schnittstellen referenzieren (mit oder ohne Zwischenadressen), gelten als auflösbar, wenn der Zustand der referenzierten Schnittstelle aktiv ist und wenn die IP-Verarbeitung auf dieser Schnittstelle aktiviert ist.

BGP-Routen referenzieren keine Schnittstellen, können aber über die Routen in der Routing-Tabelle aufgelöst werden, die von beiden Typen sein können (solche, die Schnittstellen spezifizieren, oder solche, die dies nicht tun). IGP-Routen und Routen zu direkt verbundenen Netzwerken werden erwartet, die ausgehende Schnittstelle zu spezifizieren. Statische Routen können die ausgehende Schnittstelle, die Zwischenadresse oder beides spezifizieren.

Beachten Sie, dass eine BGP-Route in einer Situation als nicht auflösbar betrachtet wird, in der die Routing-Tabelle des BGP-Speakers keine Route enthält, die mit dem NEXT_HOP der BGP-Route übereinstimmt. Gegenseitig rekursive Routen (Routen, die einander oder sich selbst auflösen) scheitern ebenfalls an der Auflösbarkeitsüberprüfung.

Es ist auch wichtig, dass Implementierungen keine machbaren Routen berücksichtigen, die nicht auflösbar würden, wenn sie in der Routing-Tabelle installiert würden, selbst wenn ihre NEXT_HOPs mit dem aktuellen Inhalt der Routing-Tabelle auflösbar sind (ein Beispiel für solche Routen wären gegenseitig rekursive Routen). Diese Überprüfung stellt sicher, dass ein BGP-Speaker keine Routen in der Routing-Tabelle installiert, die entfernt werden und vom Speaker nicht verwendet werden. Daher verbessert diese Überprüfung neben der lokalen Routing-Tabellenstabilität auch das Verhalten des Protokolls im Netzwerk.

Immer wenn ein BGP-Speaker eine Route identifiziert, die aufgrund gegenseitiger Rekursion die Auflösbarkeitsüberprüfung nicht besteht, sollte (SHOULD) eine Fehlermeldung protokolliert werden.

9.1.2.2. Breaking Ties (Phase 2) (Gleichstandsauflösung (Phase 2))

In seinen Adj-RIBs-In kann ein BGP-Speaker mehrere Routen zum gleichen Ziel haben, die den gleichen Präferenzgrad haben. Der lokale Speaker kann nur eine dieser Routen zur Aufnahme in das zugehörige Loc-RIB auswählen. Der lokale Speaker berücksichtigt alle Routen mit den gleichen Präferenzgraden, sowohl solche, die von internen Peers empfangen wurden, als auch solche, die von externen Peers empfangen wurden.

Das folgende Tie-Breaking-Verfahren setzt voraus, dass für jede Kandidatenroute alle BGP-Speaker innerhalb eines autonomen Systems die Kosten eines Pfads (innere Entfernung) zur im NEXT_HOP-Attribut der Route dargestellten Adresse ermitteln können und dem gleichen Routenauswahlalgorithmus folgen.

Der Tie-Breaking-Algorithmus beginnt damit, alle gleich bevorzugten Routen zum gleichen Ziel zu berücksichtigen, und wählt dann Routen aus, die von der Betrachtung entfernt werden sollen. Der Algorithmus endet, sobald nur noch eine Route zur Betrachtung übrig bleibt. Die Kriterien müssen (MUST) in der angegebenen Reihenfolge angewendet werden.

Mehrere der Kriterien werden mit Pseudo-Code beschrieben. Beachten Sie, dass der gezeigte Pseudo-Code der Klarheit, nicht der Effizienz wegen gewählt wurde. Er soll keine bestimmte Implementierung spezifizieren. BGP-Implementierungen können (MAY) jeden Algorithmus verwenden, der die gleichen Ergebnisse wie die hier beschriebenen erzeugt.

a) Entfernen Sie von der Betrachtung alle Routen, die nicht gleichauf sind, die kleinste Anzahl von AS-Nummern in ihren AS_PATH-Attributen zu haben. Beachten Sie, dass beim Zählen dieser Anzahl ein AS_SET als 1 zählt, unabhängig davon, wie viele ASes im Set sind.

b) Entfernen Sie von der Betrachtung alle Routen, die nicht gleichauf sind, die niedrigste Origin-Nummer in ihrem Origin-Attribut zu haben.

c) Entfernen Sie von der Betrachtung Routen mit weniger bevorzugten MULTI_EXIT_DISC-Attributen. MULTI_EXIT_DISC ist nur zwischen Routen vergleichbar, die vom gleichen benachbarten AS gelernt wurden (das benachbarte AS wird aus dem AS_PATH-Attribut bestimmt). Routen, die das MULTI_EXIT_DISC-Attribut nicht haben, werden als den niedrigstmöglichen MULTI_EXIT_DISC-Wert habend betrachtet.

Dies wird auch in der folgenden Prozedur beschrieben:

for m = all routes still under consideration for n = all routes still under consideration if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) remove route m from consideration

Im obigen Pseudo-Code ist MED(n) eine Funktion, die den Wert des MULTI_EXIT_DISC-Attributs der Route n zurückgibt. Wenn Route n kein MULTI_EXIT_DISC-Attribut hat, gibt die Funktion den niedrigstmöglichen MULTI_EXIT_DISC-Wert zurück (d.h. 0).

Ähnlich ist neighborAS(n) eine Funktion, die das benachbarte AS zurückgibt, von dem die Route empfangen wurde. Wenn die Route über IBGP gelernt wird und der andere IBGP-Speaker die Route nicht originiert hat, ist es das benachbarte AS, von dem der andere IBGP-Speaker die Route gelernt hat. Wenn die Route über IBGP gelernt wird und der andere IBGP-Speaker entweder (a) die Route originiert hat oder (b) die Route durch Aggregation erstellt hat und das AS_PATH-Attribut der aggregierten Route entweder leer ist oder mit einem AS_SET beginnt, ist es das lokale AS.

Wenn ein MULTI_EXIT_DISC-Attribut vor der Neuankündigung einer Route in IBGP entfernt wird, kann (MAY) der Vergleich basierend auf dem empfangenen EBGP MULTI_EXIT_DISC-Attribut dennoch durchgeführt werden. Wenn eine Implementierung sich entscheidet, MULTI_EXIT_DISC zu entfernen, muss (MUST) der optionale Vergleich auf MULTI_EXIT_DISC, falls durchgeführt, nur unter EBGP-gelernten Routen durchgeführt werden. Die beste EBGP-gelernte Route kann dann nach Entfernung des MULTI_EXIT_DISC-Attributs mit IBGP-gelernten Routen verglichen werden. Wenn MULTI_EXIT_DISC von einer Teilmenge von EBGP-gelernten Routen entfernt wird und die ausgewählte "beste" EBGP-gelernte Route MULTI_EXIT_DISC nicht entfernt bekommt, muss das MULTI_EXIT_DISC im Vergleich mit IBGP-gelernten Routen verwendet werden. Für IBGP-gelernte Routen muss (MUST) das MULTI_EXIT_DISC in Routenvergleichen verwendet werden, die diesen Schritt im Entscheidungsprozess erreichen. Das Einbeziehen des MULTI_EXIT_DISC einer EBGP-gelernten Route in den Vergleich mit einer IBGP-gelernten Route, dann Entfernen des MULTI_EXIT_DISC-Attributs und Ankündigen der Route hat nachweislich Routenschleifen verursacht.

d) Wenn mindestens eine der Kandidatenrouten über EBGP empfangen wurde, entfernen Sie von der Betrachtung alle Routen, die über IBGP empfangen wurden.

e) Entfernen Sie von der Betrachtung alle Routen mit weniger bevorzugten inneren Kosten. Die inneren Kosten einer Route werden bestimmt, indem die Metrik zum NEXT_HOP für die Route unter Verwendung der Routing-Tabelle berechnet wird. Wenn der NEXT_HOP-Hop für eine Route erreichbar ist, aber keine Kosten bestimmt werden können, sollte dieser Schritt übersprungen werden (äquivalent dazu, alle Routen als gleiche Kosten habend zu betrachten).

Dies wird auch in der folgenden Prozedur beschrieben.

for m = all routes still under consideration for n = all routes in still under consideration if (cost(n) is lower than cost(m)) remove m from consideration

Im obigen Pseudo-Code ist cost(n) eine Funktion, die die Kosten des Pfads (innere Entfernung) zur im NEXT_HOP-Attribut der Route angegebenen Adresse zurückgibt.

f) Entfernen Sie von der Betrachtung alle Routen außer der Route, die vom BGP-Speaker mit dem niedrigsten BGP-Identifier-Wert angekündigt wurde.

g) Bevorzugen Sie die Route, die von der niedrigsten Peer-Adresse empfangen wurde.

9.1.3. Phase 3: Route Dissemination (Phase 3: Routenverbreitung)

Die Phase-3-Entscheidungsfunktion wird bei Abschluss von Phase 2 oder wenn eines der folgenden Ereignisse eintritt aufgerufen:

a) wenn sich Routen im Loc-RIB zu lokalen Zielen geändert haben

b) wenn lokal generierte Routen, die durch Mittel außerhalb von BGP gelernt wurden, sich geändert haben

c) wenn eine neue BGP-Speaker-Verbindung hergestellt wurde

Die Phase-3-Funktion ist ein separater Prozess, der abgeschlossen wird, wenn keine weitere Arbeit mehr zu erledigen ist. Die Phase-3-Routing-Entscheidungsfunktion wird blockiert, während die Phase-2-Entscheidungsfunktion läuft.

Alle Routen im Loc-RIB werden gemäß der konfigurierten Richtlinie in Adj-RIBs-Out verarbeitet. Diese Richtlinie kann (MAY) eine Route im Loc-RIB davon ausschließen, in einem bestimmten Adj-RIB-Out installiert zu werden. Eine Route darf (SHALL NOT) im Adj-Rib-Out installiert werden, es sei denn, das Ziel und NEXT_HOP, die durch diese Route beschrieben werden, können von der Routing-Tabelle angemessen weitergeleitet werden. Wenn eine Route im Loc-RIB von einem bestimmten Adj-RIB-Out ausgeschlossen ist, muss (MUST) die zuvor in diesem Adj-RIB-Out angekündigte Route mittels einer UPDATE-Nachricht aus dem Dienst zurückgezogen werden (siehe 9.2).

Routenaggregations- und Informationsreduktionstechniken (siehe Abschnitt 9.2.2.1) können optional angewendet werden.

Jede lokale Richtlinie, die dazu führt, dass Routen zu einem Adj-RIB-Out hinzugefügt werden, ohne auch zur Weiterleitungstabelle des lokalen BGP-Speakers hinzugefügt zu werden, liegt außerhalb des Geltungsbereichs dieses Dokuments.

Wenn die Aktualisierung der Adj-RIBs-Out und der Routing-Tabelle abgeschlossen ist, führt der lokale BGP-Speaker den Update-Send-Prozess von 9.2 aus.

9.1.4. Overlapping Routes (Überlappende Routen)

Ein BGP-Speaker kann Routen mit überlappenden Network Layer Reachability Information (NLRI) an einen anderen BGP-Speaker übertragen. NLRI-Überlappung tritt auf, wenn eine Menge von Zielen in mehreren nicht übereinstimmenden Routen identifiziert wird. Da BGP NLRI mit IP-Präfixen codiert, wird Überlappung immer Teilmengenbeziehungen aufweisen. Eine Route, die eine kleinere Menge von Zielen beschreibt (ein längeres Präfix), wird als spezifischer bezeichnet als eine Route, die eine größere Menge von Zielen beschreibt (ein kürzeres Präfix); ähnlich wird eine Route, die eine größere Menge von Zielen beschreibt, als weniger spezifisch bezeichnet als eine Route, die eine kleinere Menge von Zielen beschreibt.

Die Vorrangbeziehung zerlegt effektiv weniger spezifische Routen in zwei Teile:

  • eine Menge von Zielen, die nur durch die weniger spezifische Route beschrieben werden, und

  • eine Menge von Zielen, die durch die Überlappung der weniger spezifischen und der spezifischeren Route beschrieben werden

Die Menge von Zielen, die durch die Überlappung beschrieben werden, repräsentiert einen Teil der weniger spezifischen Route, der machbar ist, aber derzeit nicht verwendet wird. Wenn eine spezifischere Route später zurückgezogen wird, bleibt die Menge von Zielen, die durch die Überlappung beschrieben werden, unter Verwendung der weniger spezifischen Route erreichbar.

Wenn ein BGP-Speaker überlappende Routen empfängt, muss (MUST) der Entscheidungsprozess beide Routen basierend auf der konfigurierten Akzeptanzrichtlinie berücksichtigen. Wenn sowohl eine weniger als auch eine spezifischere Route akzeptiert werden, muss (MUST) der Entscheidungsprozess im Loc-RIB entweder sowohl die weniger als auch die spezifischere Route installieren oder die beiden Routen aggregieren und im Loc-RIB die aggregierte Route installieren, vorausgesetzt, dass beide Routen den gleichen Wert des NEXT_HOP-Attributs haben.

Wenn ein BGP-Speaker sich entscheidet zu aggregieren, sollte (SHOULD) er entweder alle ASes, die zur Bildung des Aggregats verwendet wurden, in ein AS_SET einschließen oder das ATOMIC_AGGREGATE-Attribut zur Route hinzufügen. Dieses Attribut ist jetzt hauptsächlich informativ. Mit der Eliminierung von IP-Routing-Protokollen, die kein klassenloses Routing unterstützen, und der Eliminierung von Router- und Host-Implementierungen, die kein klassenloses Routing unterstützen, besteht keine Notwendigkeit mehr zur Disaggregation. Routen sollten nicht (SHOULD NOT) disaggregiert werden. Insbesondere darf (MUST NOT) eine Route, die das ATOMIC_AGGREGATE-Attribut trägt, nicht disaggregiert werden. Das heißt, das NLRI dieser Route kann nicht spezifischer sein. Die Weiterleitung entlang einer solchen Route garantiert nicht, dass IP-Pakete tatsächlich nur ASes durchqueren, die im AS_PATH-Attribut der Route aufgeführt sind.

9.2. Update-Send Process (Update-Send-Prozess)

Der Update-Send-Prozess ist für die Ankündigung von UPDATE-Nachrichten an alle Peers verantwortlich. Zum Beispiel verteilt er die vom Entscheidungsprozess gewählten Routen an andere BGP-Speaker, die sich entweder im gleichen autonomen System oder in einem benachbarten autonomen System befinden können.

Wenn ein BGP-Speaker eine UPDATE-Nachricht von einem internen Peer empfängt, darf (SHALL NOT) der empfangende BGP-Speaker die in dieser UPDATE-Nachricht enthaltenen Routing-Informationen nicht an andere interne Peers weiterverteilen (es sei denn, der Speaker fungiert als BGP Route Reflector [RFC2796]).

Als Teil von Phase 3 des Routenauswahlprozesses hat der BGP-Speaker seine Adj-RIBs-Out aktualisiert. Alle neu installierten Routen und alle neu nicht machbaren Routen, für die es keine Ersatzroute gibt, müssen (SHALL) mittels einer UPDATE-Nachricht an seine Peers angekündigt werden.

Ein BGP-Speaker sollte (SHOULD NOT) eine gegebene machbare BGP-Route aus seinem Adj-RIB-Out ankündigen, wenn dies eine UPDATE-Nachricht erzeugen würde, die die gleiche BGP-Route enthält wie zuvor angekündigt.

Alle Routen im Loc-RIB, die als nicht machbar markiert sind, müssen (SHALL) entfernt werden. Änderungen an den erreichbaren Zielen innerhalb seines eigenen autonomen Systems müssen (SHALL) ebenfalls in einer UPDATE-Nachricht angekündigt werden.

Wenn aufgrund der Begrenzungen der maximalen Größe einer UPDATE-Nachricht (siehe Abschnitt 4) eine einzelne Route nicht in die Nachricht passt, darf (MUST NOT) der BGP-Speaker die Route nicht an seine Peers ankündigen und kann (MAY) sich entscheiden, einen Fehler lokal zu protokollieren.

9.2.1. Controlling Routing Traffic Overhead (Kontrolle des Routing-Traffic-Overheads)

Das BGP-Protokoll beschränkt die Menge des Routing-Traffics (d.h. UPDATE-Nachrichten), um sowohl die für die Ankündigung von UPDATE-Nachrichten benötigte Link-Bandbreite als auch die vom Entscheidungsprozess benötigte Verarbeitungsleistung zum Verarbeiten der in den UPDATE-Nachrichten enthaltenen Informationen zu begrenzen.

9.2.1.1. Frequency of Route Advertisement (Häufigkeit der Routenankündigung)

Der Parameter MinRouteAdvertisementIntervalTimer bestimmt die Mindestzeit, die zwischen einer Ankündigung und/oder einem Rückzug von Routen zu einem bestimmten Ziel durch einen BGP-Speaker an einen Peer vergehen muss. Dieses Ratenbegrenzungsverfahren gilt pro Ziel, obwohl der Wert von MinRouteAdvertisementIntervalTimer pro BGP-Peer festgelegt wird.

Zwei UPDATE-Nachrichten, die von einem BGP-Speaker an einen Peer gesendet werden und machbare Routen und/oder den Rückzug nicht machbarer Routen zu einer gemeinsamen Menge von Zielen ankündigen, müssen (MUST) durch mindestens MinRouteAdvertisementIntervalTimer getrennt sein. Dies kann nur erreicht werden, indem für jede gemeinsame Menge von Zielen ein separater Timer geführt wird. Dies wäre ein ungerechtfertigter Overhead. Jede Technik, die sicherstellt, dass das Intervall zwischen zwei UPDATE-Nachrichten, die von einem BGP-Speaker an einen Peer gesendet werden und machbare Routen und/oder den Rückzug nicht machbarer Routen zu einer gemeinsamen Menge von Zielen ankündigen, mindestens MinRouteAdvertisementIntervalTimer beträgt und auch eine konstante Obergrenze für das Intervall sicherstellt, ist akzeptabel.

Da innerhalb eines autonomen Systems schnelle Konvergenz benötigt wird, sollte (SHOULD) entweder (a) der für interne Peers verwendete MinRouteAdvertisementIntervalTimer kürzer sein als der für externe Peers verwendete MinRouteAdvertisementIntervalTimer, oder (b) das in diesem Abschnitt beschriebene Verfahren sollte nicht (SHOULD NOT) auf Routen angewendet werden, die an interne Peers gesendet werden.

Dieses Verfahren begrenzt nicht die Rate der Routenauswahl, sondern nur die Rate der Routenankündigung. Wenn neue Routen mehrmals ausgewählt werden, während auf den Ablauf von MinRouteAdvertisementIntervalTimer gewartet wird, muss (SHALL) die zuletzt ausgewählte Route am Ende von MinRouteAdvertisementIntervalTimer angekündigt werden.

9.2.1.2. Frequency of Route Origination (Häufigkeit der Routenorigination)

Der Parameter MinASOriginationIntervalTimer bestimmt die Mindestzeit, die zwischen aufeinanderfolgenden Ankündigungen von UPDATE-Nachrichten vergehen muss, die Änderungen innerhalb der eigenen autonomen Systeme des ankündigenden BGP-Speakers melden.

9.2.2. Efficient Organization of Routing Information (Effiziente Organisation von Routing-Informationen)

Nachdem die anzukündigenden Routing-Informationen ausgewählt wurden, kann ein BGP-Speaker mehrere Methoden nutzen, um diese Informationen auf effiziente Weise zu organisieren.

9.2.2.1. Information Reduction (Informationsreduktion)

Informationsreduktion kann eine Reduktion der Granularität der Richtlinienkontrolle bedeuten - nachdem Informationen zusammengefasst wurden, gelten die gleichen Richtlinien für alle Ziele und Pfade in der Äquivalenzklasse.

Der Entscheidungsprozess kann optional die Menge der Informationen reduzieren, die er in die Adj-RIBs-Out aufnimmt, durch eine der folgenden Methoden:

a) Network Layer Reachability Information (NLRI):

Ziel-IP-Adressen können als IP-Adresspräfixe dargestellt werden. In Fällen, in denen eine Entsprechung zwischen der Adressstruktur und den Systemen unter Kontrolle eines autonomen Systemadministrators besteht, wird es möglich sein, die Größe des in den UPDATE-Nachrichten übertragenen NLRI zu reduzieren.

b) AS_PATHs:

AS-Pfadinformationen können als geordnete AS_SEQUENCEs oder ungeordnete AS_SETs dargestellt werden. AS_SETs werden im in Abschnitt 9.2.2.2 beschriebenen Routenaggregationsalgorithmus verwendet. Sie reduzieren die Größe der AS_PATH-Informationen, indem sie jede AS-Nummer nur einmal auflisten, unabhängig davon, wie oft sie in mehreren AS_PATHs erschienen sein mag, die aggregiert wurden.

Ein AS_SET impliziert, dass die im NLRI aufgelisteten Ziele über Pfade erreicht werden können, die zumindest einige der konstituierenden autonomen Systeme durchqueren. AS_SETs liefern ausreichende Informationen, um Routing-Informationsschleifen zu vermeiden; ihre Verwendung kann jedoch potentiell machbare Pfade beschneiden, da solche Pfade nicht mehr einzeln in Form von AS_SEQUENCEs aufgelistet werden. In der Praxis ist dies wahrscheinlich kein Problem, denn sobald ein IP-Paket am Rand einer Gruppe autonomer Systeme ankommt, hat der BGP-Speaker wahrscheinlich detailliertere Pfadinformationen und kann einzelne Pfade von Zielen unterscheiden.

9.2.2.2. Aggregating Routing Information (Aggregation von Routing-Informationen)

Aggregation ist der Prozess der Kombination der Eigenschaften mehrerer verschiedener Routen auf eine Weise, dass eine einzelne Route angekündigt werden kann. Aggregation kann als Teil des Entscheidungsprozesses erfolgen, um die Menge der Routing-Informationen zu reduzieren, die in die Adj-RIBs-Out aufgenommen werden.

Aggregation reduziert die Menge an Informationen, die ein BGP-Speaker speichern und mit anderen BGP-Speakern austauschen muss. Routen können aggregiert werden, indem das folgende Verfahren separat auf Pfadattribute des gleichen Typs und auf die Network Layer Reachability Information angewendet wird.

Routen, die unterschiedliche MULTI_EXIT_DISC-Attribute haben, dürfen nicht (SHALL NOT) aggregiert werden.

Wenn die aggregierte Route ein AS_SET als erstes Element in ihrem AS_PATH-Attribut hat, sollte (SHOULD NOT) der Router, der die Route originiert, das MULTI_EXIT_DISC-Attribut nicht mit dieser Route ankündigen.

Pfadattribute, die unterschiedliche Typcodes haben, können nicht zusammen aggregiert werden. Pfadattribute des gleichen Typcodes können gemäß den folgenden Regeln aggregiert werden:

NEXT_HOP: Beim Aggregieren von Routen, die unterschiedliche NEXT_HOP-Attribute haben, muss (SHALL) das NEXT_HOP-Attribut der aggregierten Route eine Schnittstelle auf dem BGP-Speaker identifizieren, der die Aggregation durchführt.

ORIGIN-Attribut: Wenn mindestens eine Route unter den zu aggregierenden Routen ORIGIN mit dem Wert INCOMPLETE hat, muss (MUST) die aggregierte Route das ORIGIN-Attribut mit dem Wert INCOMPLETE haben. Andernfalls, wenn mindestens eine Route unter den zu aggregierenden Routen ORIGIN mit dem Wert EGP hat, muss (MUST) die aggregierte Route das ORIGIN-Attribut mit dem Wert EGP haben. In allen anderen Fällen ist der Wert des ORIGIN-Attributs der aggregierten Route IGP.

AS_PATH-Attribut: Wenn die zu aggregierenden Routen identische AS_PATH-Attribute haben, hat die aggregierte Route das gleiche AS_PATH-Attribut wie jede einzelne Route.

Zum Zweck der Aggregation von AS_PATH-Attributen modellieren wir jedes AS innerhalb des AS_PATH-Attributs als Tupel <type, value>, wobei "type" einen Typ des Pfadsegments identifiziert, zu dem das AS gehört (z.B. AS_SEQUENCE, AS_SET), und "value" die AS-Nummer identifiziert. Wenn die zu aggregierenden Routen unterschiedliche AS_PATH-Attribute haben, muss (SHALL) das aggregierte AS_PATH-Attribut alle folgenden Bedingungen erfüllen:

  • alle Tupel vom Typ AS_SEQUENCE im aggregierten AS_PATH müssen (SHALL) in allen AS_PATHs im Anfangssatz der zu aggregierenden Routen erscheinen.

  • alle Tupel vom Typ AS_SET im aggregierten AS_PATH müssen (SHALL) in mindestens einem der AS_PATHs im Anfangssatz erscheinen (sie können entweder als AS_SET- oder AS_SEQUENCE-Typen erscheinen).

  • für jedes Tupel X vom Typ AS_SEQUENCE im aggregierten AS_PATH, das Tupel Y im aggregierten AS_PATH vorausgeht, geht X Y in jedem AS_PATH im Anfangssatz voraus, der Y enthält, unabhängig vom Typ von Y.

  • Kein Tupel vom Typ AS_SET mit dem gleichen Wert darf (SHALL) mehr als einmal im aggregierten AS_PATH erscheinen.

  • Mehrere Tupel vom Typ AS_SEQUENCE mit dem gleichen Wert dürfen im aggregierten AS_PATH nur dann erscheinen, wenn sie an ein anderes Tupel des gleichen Typs und Werts angrenzen.

Eine Implementierung kann jeden Algorithmus wählen, der diesen Regeln entspricht. Mindestens muss (SHALL) eine konforme Implementierung in der Lage sein, den folgenden Algorithmus auszuführen, der alle oben genannten Bedingungen erfüllt:

  • Bestimmen Sie die längste führende Sequenz von Tupeln (wie oben definiert), die allen AS_PATH-Attributen der zu aggregierenden Routen gemeinsam ist. Machen Sie diese Sequenz zur führenden Sequenz des aggregierten AS_PATH-Attributs.

  • Setzen Sie den Typ der restlichen Tupel aus den AS_PATH-Attributen der zu aggregierenden Routen auf AS_SET und hängen Sie sie an das aggregierte AS_PATH-Attribut an.

  • Wenn der aggregierte AS_PATH mehr als ein Tupel mit dem gleichen Wert hat (unabhängig vom Typ des Tupels), eliminieren Sie alle bis auf ein solches Tupel, indem Sie Tupel vom Typ AS_SET aus dem aggregierten AS_PATH-Attribut löschen.

  • Für jedes Paar benachbarter Tupel im aggregierten AS_PATH: Wenn beide Tupel den gleichen Typ haben, verschmelzen Sie sie zusammen, solange dies nicht zur Erzeugung eines Segments mit einer Länge größer als 255 führt.

Anhang F, Abschnitt F.6 präsentiert einen anderen Algorithmus, der die Bedingungen erfüllt und komplexere Richtlinienkonfigurationen ermöglicht.

ATOMIC_AGGREGATE: Wenn mindestens eine der zu aggregierenden Routen das ATOMIC_AGGREGATE-Pfadattribut hat, muss (SHALL) die aggregierte Route dieses Attribut ebenfalls haben.

AGGREGATOR: Alle AGGREGATOR-Attribute aus den zu aggregierenden Routen dürfen nicht (MUST NOT) in die aggregierte Route aufgenommen werden. Der BGP-Speaker, der die Routenaggregation durchführt, kann (MAY) ein neues AGGREGATOR-Attribut anhängen (siehe Abschnitt 5.1.7).

9.3. Route Selection Criteria (Routenauswahlkriterien)

Im Allgemeinen liegen zusätzliche Regeln zum Vergleichen von Routen unter mehreren Alternativen außerhalb des Geltungsbereichs dieses Dokuments. Es gibt zwei Ausnahmen:

  • Wenn das lokale AS im AS-Pfad der neuen betrachteten Route erscheint, kann diese neue Route nicht als besser als jede andere Route angesehen werden (vorausgesetzt, der Speaker ist konfiguriert, solche Routen zu akzeptieren). Wenn eine solche Route jemals verwendet würde, könnte eine Routing-Schleife resultieren.

  • Um einen erfolgreichen verteilten Betrieb zu erreichen, können nur Routen mit einer Wahrscheinlichkeit der Stabilität gewählt werden. Daher sollte (SHOULD) ein AS die Verwendung instabiler Routen vermeiden, und es sollte nicht (SHOULD NOT) schnelle, spontane Änderungen an seiner Routenwahl vornehmen. Die Quantifizierung der Begriffe "instabil" und "schnell" (aus dem vorherigen Satz) wird Erfahrung erfordern, aber das Prinzip ist klar. Routen, die instabil sind, können "bestraft" werden (z.B. durch Verwendung der in [RFC2439] beschriebenen Verfahren).

9.4. Originating BGP routes (Origination von BGP-Routen)

Ein BGP-Speaker kann BGP-Routen originieren, indem er durch andere Mittel (z.B. über ein IGP) erworbene Routing-Informationen in BGP einspeist. Ein BGP-Speaker, der BGP-Routen originiert, weist diesen Routen den Präferenzgrad (z.B. gemäß lokaler Konfiguration) zu, indem er sie durch den Entscheidungsprozess leitet (siehe Abschnitt 9.1). Diese Routen können (MAY) auch als Teil des Update-Prozesses an andere BGP-Speaker innerhalb des lokalen AS verteilt werden (siehe Abschnitt 9.2). Die Entscheidung, ob nicht-BGP-erworbene Routen innerhalb eines AS über BGP verteilt werden sollen, hängt von der Umgebung innerhalb des AS ab (z.B. Typ des IGP) und sollte (SHOULD) über die Konfiguration gesteuert werden.

Letztes Update am