5. Path Attributes (Pfadattribute)

5. Path Attributes (Pfadattribute)

   Dieser Abschnitt behandelt die Pfadattribute der UPDATE-Nachricht.

   Pfadattribute fallen in vier separate Kategorien:

   1. Well-known mandatory (Bekannte obligatorische)
   2. Well-known discretionary (Bekannte fakultative)
   3. Optional transitive (Optionale transitive)
   4. Optional non-transitive (Optionale nicht-transitive)

   BGP-Implementierungen müssen (MUST) alle bekannten Attribute erkennen. Einige dieser Attribute sind obligatorisch und müssen (MUST) in jeder UPDATE-Nachricht enthalten sein, die NLRI enthält. Andere sind fakultativ und können (MAY) in einer bestimmten UPDATE-Nachricht gesendet werden oder nicht.

   Sobald ein BGP-Peer bekannte Attribute aktualisiert hat, muss (MUST) er diese Attribute in allen Updates, die er überträgt, an seine Peers weitergeben.

   Zusätzlich zu bekannten Attributen kann (MAY) jeder Pfad ein oder mehrere optionale Attribute enthalten. Es ist nicht erforderlich oder erwartet, dass alle BGP-Implementierungen alle optionalen Attribute unterstützen. Die Behandlung eines nicht erkannten optionalen Attributs wird durch die Einstellung des Transitive-Bits im Attribut-Flags-Oktett bestimmt. Pfade mit nicht erkannten transitiven optionalen Attributen sollten (SHOULD) akzeptiert werden. Wenn ein Pfad mit einem nicht erkannten transitiven optionalen Attribut akzeptiert und an andere BGP-Peers weitergegeben wird, dann muss (MUST) das nicht erkannte transitive optionale Attribut dieses Pfads zusammen mit dem Pfad an andere BGP-Peers weitergegeben werden, wobei das Partial-Bit im Attribute-Flags-Oktett auf 1 gesetzt ist. Wenn ein Pfad mit einem erkannten transitiven optionalen Attribut akzeptiert und an andere BGP-Peers weitergegeben wird und das Partial-Bit im Attribute-Flags-Oktett von einem vorherigen AS auf 1 gesetzt wurde, darf (MUST) es vom aktuellen AS nicht auf 0 zurückgesetzt werden. Nicht erkannte nicht-transitive optionale Attribute müssen (MUST) stillschweigend ignoriert und nicht an andere BGP-Peers weitergegeben werden.

   Neue transitive optionale Attribute können (MAY) vom Initiator oder von jedem anderen BGP-Speaker im Pfad an den Pfad angehängt werden. Wenn sie nicht vom Initiator angehängt werden, wird das Partial-Bit im Attribute-Flags-Oktett auf 1 gesetzt. Die Regeln zum Anhängen neuer nicht-transitiver optionaler Attribute hängen von der Natur des spezifischen Attributs ab. Die Dokumentation jedes neuen nicht-transitiven optionalen Attributs wird voraussichtlich solche Regeln enthalten (die Beschreibung des MULTI_EXIT_DISC-Attributs gibt ein Beispiel). Alle optionalen Attribute (sowohl transitive als auch nicht-transitive) können (MAY) von BGP-Speakern im Pfad aktualisiert werden (falls angemessen).

   Der Sender einer UPDATE-Nachricht sollte (SHOULD) Pfadattribute innerhalb der UPDATE-Nachricht in aufsteigender Reihenfolge des Attributtyps ordnen. Der Empfänger einer UPDATE-Nachricht muss (MUST) darauf vorbereitet sein, Pfadattribute innerhalb von UPDATE-Nachrichten zu verarbeiten, die nicht in der richtigen Reihenfolge sind.

   Dasselbe Attribut (Attribut mit demselben Typ) kann nicht mehr als einmal innerhalb des Path-Attributes-Felds einer bestimmten UPDATE-Nachricht erscheinen.

   Die obligatorische Kategorie bezieht sich auf ein Attribut, das in IBGP- und EBGP-Austauschen vorhanden sein muss (MUST), wenn NLRI in der UPDATE-Nachricht enthalten ist. Attribute, die für den Zweck des Protokollerweiterungsmechanismus als optional klassifiziert sind, können in bestimmten Kontexten rein fakultativ, fakultativ, erforderlich oder unzulässig sein.

   attribute EBGP IBGP ORIGIN mandatory mandatory AS_PATH mandatory mandatory NEXT_HOP mandatory mandatory MULTI_EXIT_DISC discretionary discretionary LOCAL_PREF see Section 5.1.5 required ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4 AGGREGATOR discretionary discretionary

5.1. Path Attribute Usage (Verwendung von Pfadattributen)

Die Verwendung jedes BGP-Pfadattributs wird in den folgenden Klauseln beschrieben.

5.1.1. ORIGIN

ORIGIN ist ein bekanntes obligatorisches Attribut. Das ORIGIN-Attribut wird vom Speaker generiert, der die zugehörigen Routing-Informationen initiiert. Sein Wert sollte (SHOULD) nicht von einem anderen Speaker geändert werden.

5.1.2. AS_PATH

AS_PATH ist ein bekanntes obligatorisches Attribut. Dieses Attribut identifiziert die autonomen Systeme, durch die die in dieser UPDATE-Nachricht übertragenen Routing-Informationen gegangen sind. Die Komponenten dieser Liste können AS_SETs oder AS_SEQUENCEs sein.

Wenn ein BGP-Speaker eine Route propagiert, die er aus der UPDATE-Nachricht eines anderen BGP-Speakers gelernt hat, modifiziert er das AS_PATH-Attribut der Route basierend auf dem Standort des BGP-Speakers, an den die Route gesendet wird:

a) Wenn ein gegebener BGP-Speaker die Route an einen internen Peer ankündigt, darf (SHALL) der ankündigende Speaker das AS_PATH-Attribut, das der Route zugeordnet ist, nicht modifizieren.

b) Wenn ein gegebener BGP-Speaker die Route an einen externen Peer ankündigt, aktualisiert der ankündigende Speaker das AS_PATH-Attribut wie folgt:

1. Wenn das erste Pfadsegment des AS_PATH vom Typ AS_SEQUENCE ist, stellt das lokale System seine eigene AS-Nummer als letztes Element der Sequenz voran (platziert es in der am weitesten links gelegenen Position in Bezug auf die Position der Oktette in der Protokollnachricht). Wenn das Voranstellen einen Überlauf im AS_PATH-Segment verursacht (d.h. mehr als 255 ASes), sollte (SHOULD) es ein neues Segment vom Typ AS_SEQUENCE voranstellen und seine eigene AS-Nummer diesem neuen Segment voranstellen.

2. Wenn das erste Pfadsegment des AS_PATH vom Typ AS_SET ist, stellt das lokale System ein neues Pfadsegment vom Typ AS_SEQUENCE dem AS_PATH voran und fügt seine eigene AS-Nummer in dieses Segment ein.

3. Wenn der AS_PATH leer ist, erstellt das lokale System ein Pfadsegment vom Typ AS_SEQUENCE, platziert sein eigenes AS in dieses Segment und platziert dieses Segment in den AS_PATH.

Wenn ein BGP-Speaker eine Route initiiert, dann:

a) fügt der initiierende Speaker seine eigene AS-Nummer in ein Pfadsegment vom Typ AS_SEQUENCE im AS_PATH-Attribut aller UPDATE-Nachrichten ein, die an einen externen Peer gesendet werden. In diesem Fall ist die AS-Nummer des autonomen Systems des initiierenden Speakers der einzige Eintrag im Pfadsegment, und dieses Pfadsegment ist das einzige Segment im AS_PATH-Attribut.

b) fügt der initiierende Speaker ein leeres AS_PATH-Attribut in alle UPDATE-Nachrichten ein, die an interne Peers gesendet werden. (Ein leeres AS_PATH-Attribut ist eines, dessen Längenfeld den Wert Null enthält).

Wann immer die Modifikation des AS_PATH-Attributs das Einschließen oder Voranstellen der AS-Nummer des lokalen Systems erfordert, kann (MAY) das lokale System mehr als eine Instanz seiner eigenen AS-Nummer im AS_PATH-Attribut einschließen/voranstellen. Dies wird über die lokale Konfiguration gesteuert.

5.1.3. NEXT_HOP

Der NEXT_HOP ist ein bekanntes obligatorisches Attribut, das die IP-Adresse des Routers definiert, der als nächster Hop zu den in der UPDATE-Nachricht aufgelisteten Zielen verwendet werden sollte (SHOULD). Das NEXT_HOP-Attribut wird wie folgt berechnet:

1. Beim Senden einer Nachricht an einen internen Peer sollte (SHOULD) der BGP-Speaker das NEXT_HOP-Attribut nicht modifizieren, wenn die Route nicht lokal initiiert wurde, es sei denn, er wurde explizit konfiguriert, seine eigene IP-Adresse als NEXT_HOP anzukündigen. Beim Ankündigen einer lokal initiierten Route an einen internen Peer sollte (SHOULD) der BGP-Speaker die Schnittstellenadresse des Routers verwenden, über den das angekündigte Netzwerk für den Speaker erreichbar ist, als NEXT_HOP. Wenn die Route direkt mit dem Speaker verbunden ist oder wenn die Schnittstellenadresse des Routers, über den das angekündigte Netzwerk für den Speaker erreichbar ist, die Adresse des internen Peers ist, dann sollte (SHOULD) der BGP-Speaker seine eigene IP-Adresse für das NEXT_HOP-Attribut verwenden (die Adresse der Schnittstelle, die verwendet wird, um den Peer zu erreichen).

2. Beim Senden einer Nachricht an einen externen Peer X, und der Peer ist einen IP-Hop vom Speaker entfernt:

   • Wenn die angekündigte Route von einem internen Peer gelernt wurde oder lokal initiiert wurde, kann der BGP-Speaker eine Schnittstellenadresse des internen Peer-Routers (oder des internen Routers) verwenden, über den das angekündigte Netzwerk für den Speaker erreichbar ist, für das NEXT_HOP-Attribut, vorausgesetzt, dass Peer X ein gemeinsames Subnetz mit dieser Adresse teilt. Dies ist eine Form des "Drittanbieter"-NEXT_HOP-Attributs.

   • Andernfalls kann der Speaker, wenn die angekündigte Route von einem externen Peer gelernt wurde, eine IP-Adresse eines beliebigen benachbarten Routers (bekannt aus dem empfangenen NEXT_HOP-Attribut) verwenden, die der Speaker selbst für die lokale Routenberechnung im NEXT_HOP-Attribut verwendet, vorausgesetzt, dass Peer X ein gemeinsames Subnetz mit dieser Adresse teilt. Dies ist eine zweite Form des "Drittanbieter"-NEXT_HOP-Attributs.

   • Andernfalls kann (MAY) der Speaker, wenn der externe Peer, an den die Route angekündigt wird, ein gemeinsames Subnetz mit einer der Schnittstellen des ankündigenden BGP-Speakers teilt, die mit einer solchen Schnittstelle verbundene IP-Adresse im NEXT_HOP-Attribut verwenden. Dies wird als "Erstanbieter"-NEXT_HOP-Attribut bezeichnet.

   • Standardmäßig (wenn keine der obigen Bedingungen zutrifft) sollte (SHOULD) der BGP-Speaker die IP-Adresse der Schnittstelle verwenden, die der Speaker verwendet, um die BGP-Verbindung zu Peer X im NEXT_HOP-Attribut herzustellen.

3. Beim Senden einer Nachricht an einen externen Peer X, und der Peer ist mehrere IP-Hops vom Speaker entfernt (auch bekannt als "Multihop-EBGP"):

   • Der Speaker kann (MAY) so konfiguriert werden, dass er das NEXT_HOP-Attribut propagiert. In diesem Fall ist das NEXT_HOP-Attribut der angekündigten Route beim Ankündigen einer Route, die der Speaker von einem seiner Peers gelernt hat, genau dasselbe wie das NEXT_HOP-Attribut der gelernten Route (der Speaker modifiziert das NEXT_HOP-Attribut nicht).

   • Standardmäßig sollte (SHOULD) der BGP-Speaker die IP-Adresse der Schnittstelle verwenden, die der Speaker im NEXT_HOP-Attribut verwendet, um die BGP-Verbindung zu Peer X herzustellen.

Normalerweise wird das NEXT_HOP-Attribut so gewählt, dass der kürzeste verfügbare Pfad genommen wird. Ein BGP-Speaker muss (MUST) in der Lage sein, die Deaktivierung der Ankündigung von Drittanbieter-NEXT_HOP-Attributen zu unterstützen, um unvollständig überbrückte Medien zu handhaben.

Eine von einem BGP-Speaker initiierte Route darf (SHALL) nicht unter Verwendung einer Adresse dieses Peers als NEXT_HOP an einen Peer angekündigt werden. Ein BGP-Speaker darf (SHALL) keine Route mit sich selbst als nächstem Hop installieren.

Das NEXT_HOP-Attribut wird vom BGP-Speaker verwendet, um die tatsächliche ausgehende Schnittstelle und die unmittelbare Next-Hop-Adresse zu bestimmen, die verwendet werden sollte (SHOULD), um Transitpakete an die zugehörigen Ziele weiterzuleiten.

Die unmittelbare Next-Hop-Adresse wird bestimmt, indem eine rekursive Routenlookup-Operation für die IP-Adresse im NEXT_HOP-Attribut durchgeführt wird, wobei der Inhalt der Routing-Tabelle verwendet wird und ein Eintrag ausgewählt wird, wenn mehrere Einträge gleicher Kosten existieren. Der Routing-Tabelleneintrag, der die IP-Adresse im NEXT_HOP-Attribut auflöst, gibt immer die ausgehende Schnittstelle an. Wenn der Eintrag ein angehängtes Subnetz angibt, aber keine Next-Hop-Adresse angibt, dann sollte (SHOULD) die Adresse im NEXT_HOP-Attribut als unmittelbare Next-Hop-Adresse verwendet werden. Wenn der Eintrag auch die Next-Hop-Adresse angibt, sollte (SHOULD) diese Adresse als unmittelbare Next-Hop-Adresse für die Paketweiterleitung verwendet werden.

5.1.4. MULTI_EXIT_DISC

Der MULTI_EXIT_DISC ist ein optionales nicht-transitives Attribut, das auf externen (Inter-AS-)Links verwendet werden soll, um zwischen mehreren Aus- oder Eingangspunkten zum selben benachbarten AS zu unterscheiden. Der Wert des MULTI_EXIT_DISC-Attributs ist eine vorzeichenlose Vier-Oktett-Zahl, die als Metrik bezeichnet wird. Wenn alle anderen Faktoren gleich sind, sollte (SHOULD) der Ausgangspunkt mit der niedrigeren Metrik bevorzugt werden. Wenn über EBGP empfangen, kann (MAY) das MULTI_EXIT_DISC-Attribut über IBGP an andere BGP-Speaker innerhalb desselben AS propagiert werden (siehe auch 9.1.2.2). Das von einem benachbarten AS empfangene MULTI_EXIT_DISC-Attribut darf (MUST) nicht an andere benachbarte ASe propagiert werden.

Ein BGP-Speaker muss (MUST) einen Mechanismus (basierend auf lokaler Konfiguration) implementieren, der es ermöglicht, das MULTI_EXIT_DISC-Attribut von einer Route zu entfernen. Wenn ein BGP-Speaker so konfiguriert ist, dass er das MULTI_EXIT_DISC-Attribut von einer Route entfernt, dann muss (MUST) diese Entfernung vor der Bestimmung des Präferenzgrads der Route und vor der Durchführung der Routenauswahl (Entscheidungsprozess Phasen 1 und 2) erfolgen.

Eine Implementierung kann (MAY) auch (basierend auf lokaler Konfiguration) den Wert des über EBGP empfangenen MULTI_EXIT_DISC-Attributs ändern. Wenn ein BGP-Speaker so konfiguriert ist, dass er den Wert des über EBGP empfangenen MULTI_EXIT_DISC-Attributs ändert, dann muss (MUST) die Wertänderung vor der Bestimmung des Präferenzgrads der Route und vor der Durchführung der Routenauswahl (Entscheidungsprozess Phasen 1 und 2) erfolgen. Siehe Abschnitt 9.1.2.2 für notwendige Einschränkungen hierzu.

5.1.5. LOCAL_PREF

LOCAL_PREF ist ein bekanntes Attribut, das in allen UPDATE-Nachrichten enthalten sein muss (SHALL), die ein gegebener BGP-Speaker an andere interne Peers sendet. Ein BGP-Speaker muss (SHALL) den Präferenzgrad für jede externe Route basierend auf der lokal konfigurierten Richtlinie berechnen und den Präferenzgrad einschließen, wenn er eine Route an seine internen Peers ankündigt. Der höhere Präferenzgrad muss (MUST) bevorzugt werden. Ein BGP-Speaker verwendet den über LOCAL_PREF gelernten Präferenzgrad in seinem Entscheidungsprozess (siehe Abschnitt 9.1.1).

Ein BGP-Speaker darf (MUST) dieses Attribut nicht in UPDATE-Nachrichten einschließen, die er an externe Peers sendet, außer im Fall von BGP-Konföderationen [RFC3065]. Wenn es in einer UPDATE-Nachricht enthalten ist, die von einem externen Peer empfangen wird, dann muss (MUST) dieses Attribut vom empfangenden Speaker ignoriert werden, außer im Fall von BGP-Konföderationen [RFC3065].

5.1.6. ATOMIC_AGGREGATE

ATOMIC_AGGREGATE ist ein bekanntes fakultatives Attribut.

Wenn ein BGP-Speaker mehrere Routen zum Zweck der Ankündigung an einen bestimmten Peer aggregiert, enthält der AS_PATH der aggregierten Route normalerweise ein AS_SET, das aus der Menge der ASe gebildet wird, aus denen das Aggregat gebildet wurde. In vielen Fällen kann der Netzwerkadministrator bestimmen, ob das Aggregat sicher ohne das AS_SET und ohne Bildung von Routenschleifen angekündigt werden kann.

Wenn ein Aggregat mindestens einige der AS-Nummern ausschließt, die im AS_PATH der aggregierten Routen vorhanden sind, als Ergebnis des Weglassens des AS_SET, sollte (SHOULD) die aggregierte Route, wenn sie an den Peer angekündigt wird, das ATOMIC_AGGREGATE-Attribut enthalten.

Ein BGP-Speaker, der eine Route mit dem ATOMIC_AGGREGATE-Attribut empfängt, sollte (SHOULD) das Attribut beim Propagieren der Route an andere Speaker nicht entfernen.

Ein BGP-Speaker, der eine Route mit dem ATOMIC_AGGREGATE-Attribut empfängt, darf (MUST) beim Ankündigen dieser Route an andere BGP-Speaker kein NLRI dieser Route spezifischer machen (wie in 9.1.4 definiert).

Ein BGP-Speaker, der eine Route mit dem ATOMIC_AGGREGATE-Attribut empfängt, muss sich der Tatsache bewusst sein, dass der tatsächliche Pfad zu Zielen, wie im NLRI der Route angegeben, obwohl er die schleifenfreie Eigenschaft hat, möglicherweise nicht der im AS_PATH-Attribut der Route angegebene Pfad ist.

5.1.7. AGGREGATOR

AGGREGATOR ist ein optionales transitives Attribut, das in Updates enthalten sein kann (MAY), die durch Aggregation gebildet werden (siehe Abschnitt 9.2.2.2). Ein BGP-Speaker, der Routenaggregation durchführt, kann (MAY) das AGGREGATOR-Attribut hinzufügen, das seine eigene AS-Nummer und IP-Adresse enthalten muss (SHALL). Die IP-Adresse sollte (SHOULD) dieselbe sein wie der BGP-Identifier des Speakers.