3. Zusammenfassung der Operation (Summary of Operation)
Das Border Gateway Protocol (BGP) ist ein Inter-Autonomous-System-Routing-Protokoll. Es basiert auf Erfahrungen mit EGP (wie in [RFC904] definiert) und der EGP-Nutzung im NSFNET Backbone (wie in [RFC1092] und [RFC1093] beschrieben). Für weitere BGP-bezogene Informationen siehe [RFC1772], [RFC1930], [RFC1997] und [RFC2858].
Die Hauptfunktion eines BGP-sprechenden Systems besteht darin, Netzwerk-Erreichbarkeitsinformationen mit anderen BGP-Systemen auszutauschen. Diese Netzwerk-Erreichbarkeitsinformationen umfassen Informationen über die Liste der autonomen Systeme (ASes), die die Erreichbarkeitsinformationen durchlaufen. Diese Informationen reichen aus, um einen Graphen der AS-Konnektivität zu erstellen, aus dem Routing-Schleifen entfernt werden können und auf AS-Ebene einige Richtlinienentscheidungen durchgesetzt werden können.
Im Kontext dieses Dokuments gehen wir davon aus, dass ein BGP-Speaker seinen Peers nur solche Routen ankündigt, die er selbst verwendet (in diesem Kontext wird gesagt, dass ein BGP-Speaker eine BGP-Route "verwendet", wenn es die bevorzugteste BGP-Route ist und beim Forwarding verwendet wird). Alle anderen Fälle liegen außerhalb des Geltungsbereichs dieses Dokuments.
Im Kontext dieses Dokuments bezieht sich der Begriff "IP-Adresse" auf eine IP-Version-4-Adresse [RFC791].
Die über BGP ausgetauschten Routing-Informationen unterstützen nur das zielbasierte Weiterleitungsparadigma, das davon ausgeht, dass ein Router ein Paket ausschließlich basierend auf der Zieladresse weiterleitet, die im IP-Header des Pakets enthalten ist. Dies wiederum spiegelt die Menge der Richtlinienentscheidungen wider, die mit BGP durchgesetzt werden können (und nicht durchgesetzt werden können). Beachten Sie, dass einige Richtlinien vom zielbasierten Weiterleitungsparadigma nicht unterstützt werden können und daher Techniken wie Source Routing (auch explizites Routing genannt) erfordern, um durchgesetzt zu werden. Solche Richtlinien können auch mit BGP nicht durchgesetzt werden. Beispielsweise ermöglicht BGP es nicht, dass ein AS Verkehr an ein benachbartes AS sendet, um ihn zu einem Ziel weiterzuleiten (das über dieses benachbarte AS erreichbar ist, aber darüber hinaus liegt), mit der Absicht, dass der Verkehr eine andere Route nimmt als der Verkehr, der im benachbarten AS für dasselbe Ziel entsteht. Andererseits kann BGP jede Richtlinie unterstützen, die dem zielbasierten Weiterleitungsparadigma entspricht.
BGP-4 bietet eine neue Reihe von Mechanismen zur Unterstützung von Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. Diese Mechanismen umfassen die Unterstützung für die Ankündigung einer Reihe von Zielen als IP-Präfix und die Beseitigung des Konzepts einer Netzwerk-"Klasse" innerhalb von BGP. BGP-4 führt auch Mechanismen ein, die eine Aggregation von Routen ermöglichen, einschließlich der Aggregation von AS-Pfaden.
Dieses Dokument verwendet durchgehend den Begriff "Autonomes System" (AS). Die klassische Definition eines autonomen Systems ist eine Reihe von Routern unter einer einzigen technischen Verwaltung, die ein Interior Gateway Protocol (IGP) und gemeinsame Metriken verwenden, um zu bestimmen, wie Pakete innerhalb des AS geroutet werden, und die ein Inter-AS-Routing-Protokoll verwenden, um zu bestimmen, wie Pakete zu anderen ASes geroutet werden. Seit diese klassische Definition entwickelt wurde, ist es üblich geworden, dass ein einzelnes AS mehrere IGPs und manchmal mehrere Metrik-Sets innerhalb eines AS verwendet. Die Verwendung des Begriffs Autonomes System betont die Tatsache, dass die Verwaltung eines AS anderen ASes gegenüber auch dann als einheitlicher und kohärenter interner Routing-Plan erscheint, wenn mehrere IGPs und Metriken verwendet werden, und ein konsistentes Bild der Ziele präsentiert, die darüber erreichbar sind.
BGP verwendet TCP [RFC793] als Transportprotokoll. Dies eliminiert die Notwendigkeit, explizite Update-Fragmentierung, Neuübertragung, Bestätigung und Sequenzierung zu implementieren. BGP hört auf TCP-Port 179. Der in BGP verwendete Fehlerbenachrichtigungsmechanismus setzt voraus, dass TCP ein "graceful" Close unterstützt (d. h., dass alle ausstehenden Daten geliefert werden, bevor die Verbindung geschlossen wird).
Eine TCP-Verbindung wird zwischen zwei Systemen hergestellt. Sie tauschen Nachrichten aus, um die Verbindungsparameter zu öffnen und zu bestätigen.
Der anfängliche Datenfluss ist der Teil der BGP-Routing-Tabelle, der durch die Export-Policy zugelassen wird, genannt Adj-Ribs-Out (siehe 3.2). Inkrementelle Updates werden gesendet, wenn sich die Routing-Tabellen ändern. BGP erfordert keine periodische Aktualisierung der Routing-Tabelle. Um lokalen Policy-Änderungen zu ermöglichen, die korrekte Wirkung zu haben, ohne BGP-Verbindungen zurückzusetzen, sollte (SHOULD) ein BGP-Speaker entweder (a) die aktuelle Version der von allen seinen Peers angekündigten Routen für die Dauer der Verbindung beibehalten oder (b) die Route Refresh-Erweiterung [RFC2918] nutzen.
KEEPALIVE-Nachrichten können (MAY) periodisch gesendet werden, um sicherzustellen, dass die Verbindung aktiv ist. NOTIFICATION-Nachrichten werden als Reaktion auf Fehler oder besondere Bedingungen gesendet. Wenn eine Verbindung auf eine Fehlerbedingung stößt, wird eine NOTIFICATION-Nachricht gesendet und die Verbindung geschlossen.
Ein Peer in einem anderen AS wird als externer Peer bezeichnet, während ein Peer im selben AS als interner Peer bezeichnet wird. Internes BGP und externes BGP werden üblicherweise als IBGP und EBGP abgekürzt.
Wenn ein bestimmtes AS mehrere BGP-Speaker hat und Transit-Service für andere ASes bereitstellt, muss darauf geachtet werden, eine konsistente Sicht des Routings innerhalb des AS sicherzustellen. Eine konsistente Sicht der internen Routen des AS wird durch das innerhalb des AS verwendete IGP bereitgestellt. Für die Zwecke dieses Dokuments wird angenommen, dass eine konsistente Sicht der externen Routen des AS dadurch bereitgestellt wird, dass alle BGP-Speaker innerhalb des AS IBGP miteinander unterhalten.
Dieses Dokument spezifiziert das Basisverhalten des BGP-Protokolls. Dieses Verhalten kann durch Erweiterungsspezifikationen modifiziert werden und wird auch modifiziert. Wenn das Protokoll erweitert wird, wird das neue Verhalten vollständig in den Erweiterungsspezifikationen dokumentiert.
3.1. Routen: Ankündigung und Speicherung (Routes: Advertisement and Storage)
Für die Zwecke dieses Protokolls ist eine Route als eine Informationseinheit definiert, die eine Reihe von Zielen mit den Attributen eines Pfads zu diesen Zielen paart. Die Menge der Ziele sind Systeme, deren IP-Adressen in einem IP-Adresspräfix enthalten sind, das im NLRI-Feld (Network Layer Reachability Information) einer UPDATE-Nachricht übertragen wird, und der Pfad ist die Information, die im Pfadattributfeld derselben UPDATE-Nachricht gemeldet wird.
Routen werden zwischen BGP-Speakern in UPDATE-Nachrichten angekündigt. Mehrere Routen mit denselben Pfadattributen können in einer einzigen UPDATE-Nachricht angekündigt werden, indem mehrere Präfixe in das NLRI-Feld der UPDATE-Nachricht aufgenommen werden.
Routen werden in den Routing Information Bases (RIBs) gespeichert: nämlich in den Adj-RIBs-In, dem Loc-RIB und den Adj-RIBs-Out, wie in Abschnitt 3.2 beschrieben.
Wenn ein BGP-Speaker eine zuvor empfangene Route ankündigen möchte, kann (MAY) er die Pfadattribute der Route hinzufügen oder ändern, bevor er sie einem Peer ankündigt.
BGP bietet Mechanismen, durch die ein BGP-Speaker seine Peers informieren kann, dass eine zuvor angekündigte Route nicht mehr zur Verwendung verfügbar ist. Es gibt drei Methoden, mit denen ein gegebener BGP-Speaker anzeigen kann, dass eine Route aus dem Dienst zurückgezogen wurde:
a) das IP-Präfix, das das Ziel für eine zuvor angekündigte Route ausdrückt, kann im Feld WITHDRAWN ROUTES der UPDATE-Nachricht angekündigt werden, wodurch die zugehörige Route als nicht mehr zur Verwendung verfügbar gekennzeichnet wird,
b) eine Ersatzroute mit demselben NLRI kann angekündigt werden, oder
c) die BGP-Speaker-Verbindung kann geschlossen werden, wodurch implizit alle Routen, die das Speaker-Paar gegenseitig angekündigt hatte, aus dem Dienst entfernt werden.
Die Änderung der Attribut(e) einer Route wird durch Ankündigung einer Ersatzroute erreicht. Die Ersatzroute trägt neue (geänderte) Attribute und hat dasselbe Adresspräfix wie die ursprüngliche Route.
3.2. Routing-Informationsbasis (Routing Information Base)
Die Routing-Informationsbasis (Routing Information Base, RIB) innerhalb eines BGP-Speakers besteht aus drei verschiedenen Teilen:
a) Adj-RIBs-In: Die Adj-RIBs-In speichern Routing-Informationen, die aus eingehenden UPDATE-Nachrichten gelernt wurden, die von anderen BGP-Speakern empfangen wurden. Ihr Inhalt repräsentiert Routen, die als Eingabe für den Entscheidungsprozess (Decision Process) verfügbar sind.
b) Loc-RIB: Das Loc-RIB enthält die lokalen Routing-Informationen, die der BGP-Speaker durch Anwendung seiner lokalen Policies auf die in seinen Adj-RIBs-In enthaltenen Routing-Informationen ausgewählt hat. Dies sind die Routen, die vom lokalen BGP-Speaker verwendet werden. Der Next Hop für jede dieser Routen muss (MUST) über die Routing-Tabelle des lokalen BGP-Speakers auflösbar sein.
c) Adj-RIBs-Out: Die Adj-RIBs-Out speichern Informationen, die der lokale BGP-Speaker für die Ankündigung an seine Peers ausgewählt hat. Die in den Adj-RIBs-Out gespeicherten Routing-Informationen werden in den UPDATE-Nachrichten des lokalen BGP-Speakers übertragen und seinen Peers angekündigt.
Zusammenfassend enthalten die Adj-RIBs-In unverarbeitete Routing-Informationen, die dem lokalen BGP-Speaker von seinen Peers angekündigt wurden; das Loc-RIB enthält die Routen, die vom Entscheidungsprozess des lokalen BGP-Speakers ausgewählt wurden; und die Adj-RIBs-Out organisieren die Routen für die Ankündigung an bestimmte Peers (mittels der UPDATE-Nachrichten des lokalen Speakers).
Obwohl das konzeptionelle Modell zwischen Adj-RIBs-In, Loc-RIB und Adj-RIBs-Out unterscheidet, impliziert oder erfordert dies nicht, dass eine Implementierung drei separate Kopien der Routing-Informationen pflegen muss. Die Wahl der Implementierung (z. B. 3 Kopien der Information vs. 1 Kopie mit Zeigern) ist nicht durch das Protokoll eingeschränkt.
Routing-Informationen, die der BGP-Speaker zum Weiterleiten von Paketen verwendet (oder zum Erstellen der für die Paketweiterleitung verwendeten Weiterleitungstabelle), werden in der Routing-Tabelle (Routing Table) gepflegt. Die Routing-Tabelle sammelt Routen zu direkt verbundenen Netzwerken, statische Routen, von IGP-Protokollen gelernte Routen und von BGP gelernte Routen. Ob eine bestimmte BGP-Route in die Routing-Tabelle installiert werden sollte und ob eine BGP-Route eine von einer anderen Quelle installierte Route zum selben Ziel überschreiben sollte, ist eine lokale Policy-Entscheidung und wird in diesem Dokument nicht spezifiziert. Zusätzlich zur tatsächlichen Paketweiterleitung wird die Routing-Tabelle für die Auflösung der in BGP-Updates angegebenen Next-Hop-Adressen verwendet (siehe Abschnitt 5.1.3).