4. Betrieb

4.1. Interaktion zwischen NEUEN BGP-Sprechern

Ein BGP-Sprecher, der Vier-Oktett-AS-Nummern unterstützt, SOLL (SHALL) dies seinen Peers unter Verwendung von BGP-Fähigkeitsankündigungen mitteilen. Die AS-Nummer des BGP-Sprechers MUSS (MUST) im Capability Value Feld der „Unterstützung für Vier-Oktett-AS-Nummern-Fähigkeit" transportiert werden.

Wenn ein NEUER BGP-Sprecher eine OPEN-Nachricht von einem anderen NEUEN BGP-Sprecher verarbeitet, MUSS (MUST) er die im Capability Value Feld der „Unterstützung für Vier-Oktett-AS-Nummern-Fähigkeit" kodierte AS-Nummer anstelle des Feldes „My Autonomous System" der OPEN-Nachricht verwenden.

Ein BGP-Sprecher, der eine solche Fähigkeit einem bestimmten Peer ankündigt und von diesem Peer die Ankündigung einer solchen Fähigkeit erhält, MUSS (MUST) AS-Nummern als Vier-Oktett-Entitäten sowohl im AS_PATH-Attribut als auch im AGGREGATOR-Attribut in den Updates, die er an den Peer sendet, kodieren und MUSS (MUST) davon ausgehen, dass diese Attribute in den vom Peer empfangenen Updates AS-Nummern als Vier-Oktett-Entitäten kodieren.

Die neuen Attribute AS4_PATH und AS4_AGGREGATOR DÜRFEN NICHT (MUST NOT) in einer UPDATE-Nachricht zwischen NEUEN BGP-Sprechern transportiert werden. Ein NEUER BGP-Sprecher, der das AS4_PATH-Attribut oder das AS4_AGGREGATOR-Attribut in einer UPDATE-Nachricht von einem anderen NEUEN BGP-Sprecher empfängt, MUSS (MUST) das Pfadattribut verwerfen und die Verarbeitung der UPDATE-Nachricht fortsetzen.

4.2. Interaktion zwischen NEUEN und ALTEN BGP-Sprechern

4.2.1. BGP-Peering

Beachten Sie, dass Peering zwischen einem NEUEN BGP-Sprecher und einem ALTEN BGP-Sprecher nur dann möglich ist, wenn der NEUE BGP-Sprecher eine Zwei-Oktett-AS-Nummer hat. Dieses Dokument geht jedoch nicht davon aus, dass ein autonomes System mit NEUEN BGP-Sprechern eine global eindeutige Zwei-Oktett-AS-Nummer haben muss – AS_TRANS MUSS (MUST) verwendet werden, wenn der NEUE BGP-Sprecher keine Zwei-Oktett-AS-Nummer hat (selbst wenn mehrere autonome Systeme sie verwenden würden).

4.2.2. Generieren von Updates

Bei der Kommunikation mit einem ALTEN BGP-Sprecher MUSS (MUST) ein NEUER BGP-Sprecher die AS-Pfadinformationen im AS_PATH-Attribut mit Zwei-Oktett-AS-Nummern kodiert senden. Der NEUE BGP-Sprecher MUSS (MUST) auch die AS-Pfadinformationen im AS4_PATH-Attribut (mit Vier-Oktett-AS-Nummern kodiert) senden, außer in dem Fall, dass alle AS-Pfadinformationen nur aus abbildbaren Vier-Oktett-AS-Nummern bestehen. In diesem Fall DARF (MUST NOT) der NEUE BGP-Sprecher das AS4_PATH-Attribut NICHT senden.

Im AS_PATH-Attribut, das mit Zwei-Oktett-AS-Nummern kodiert ist, werden nicht abbildbare Vier-Oktett-AS-Nummern durch die bekannte Zwei-Oktett-AS-Nummer AS_TRANS dargestellt. Dies bewahrt die Pfadlängeneigenschaft der AS-Pfadinformationen und hilft auch beim Aktualisieren der AS-Pfadinformationen, die auf einem NEUEN BGP-Sprecher von einem ALTEN BGP-Sprecher empfangen werden, wie im nächsten Abschnitt erklärt.

Der NEUE BGP-Sprecher konstruiert das AS4_PATH-Attribut aus den AS-Pfadinformationen. Wenn die AS-Pfadinformationen das AS_CONFED_SEQUENCE- oder AS_CONFED_SET-Pfadsegment enthalten, MUSS (MUST) der NEUE BGP-Sprecher solche Pfadsegmente aus dem zu konstruierenden AS4_PATH-Attribut ausschließen.

Das AS4_PATH-Attribut, das optional transitiv ist, wird über eine Reihe von ALTEN BGP-Sprechern ohne Änderung transportiert und hilft dabei, die nicht abbildbaren Vier-Oktett-AS-Nummern in den AS-Pfadinformationen zu bewahren.

Ebenso, wenn der NEUE BGP-Sprecher das AGGREGATOR-Attribut senden muss und die AS-Nummer des aggregierenden autonomen Systems eine nicht abbildbare Vier-Oktett-AS-Nummer ist, dann MUSS (MUST) der Sprecher das AS4_AGGREGATOR-Attribut verwenden und das AS-Nummernfeld im bestehenden AGGREGATOR-Attribut auf die reservierte AS-Nummer AS_TRANS setzen. Beachten Sie, dass wenn die AS-Nummer abbildbar ist, das AS4_AGGREGATOR-Attribut NICHT (MUST NOT) gesendet werden DARF.

4.2.3. Verarbeitung empfangener Updates

Wenn ein NEUER BGP-Sprecher ein Update von einem ALTEN BGP-Sprecher empfängt, MUSS (MUST) er darauf vorbereitet sein, das AS4_PATH-Attribut zusammen mit dem bestehenden AS_PATH-Attribut zu empfangen. Wenn auch das AS4_PATH-Attribut empfangen wird, werden beide Attribute verwendet, um die genauen AS-Pfadinformationen zu konstruieren, und daher werden die von beiden Attributen transportierten Informationen für die AS-Pfadschleifenerkennung berücksichtigt.

Beachten Sie, dass eine Route eine Reihe von autonomen Systemen mit Zwei-Oktett-AS-Nummern und nur ALTEN BGP-Sprechern durchlaufen haben kann. In diesem Fall, wenn die Route das AS4_PATH-Attribut trägt, wäre dieses Attribut seit dem Verlassen des letzten NEUEN BGP-Sprechers unverändert geblieben. Die nachfolgenden AS-Pfadinformationen (die autonome Systeme mit Zwei-Oktett-AS-Nummern und nur ALTE BGP-Sprecher repräsentieren) sind nur im aktuellen AS_PATH-Attribut enthalten (im führenden Teil des AS_PATH-Attributs kodiert).

Unter bestimmten Bedingungen ist es möglicherweise nicht möglich, alle AS-Pfadinformationen aus den AS_PATH- und AS4_PATH-Attributen einer Route zu rekonstruieren. Dies tritt beispielsweise auf, wenn zwei oder mehr Routen, die das AS4_PATH-Attribut tragen, von einem ALTEN BGP-Sprecher aggregiert werden und das AS4_PATH-Attribut mindestens einer dieser Routen mindestens eine Vier-Oktett-AS-Nummer trägt (im Gegensatz zu einer Zwei-Oktett-AS-Nummer, die in 4 Oktetten kodiert ist). Je nach Implementierung würde entweder das AS4_PATH-Attribut während der Routenaggregation verloren gehen, oder sowohl das AS_PATH-Attribut als auch das AS4_PATH-Attribut würden gültige, partielle Informationen enthalten, die nicht nahtlos kombiniert werden können, was in diesen Fällen zu unvollständigen AS-Pfadinformationen führt.

Ein NEUER BGP-Sprecher MUSS (MUST) auch darauf vorbereitet sein, das AS4_AGGREGATOR-Attribut zusammen mit dem AGGREGATOR-Attribut von einem ALTEN BGP-Sprecher zu empfangen. Wenn beide Attribute empfangen werden und die AS-Nummer im AGGREGATOR-Attribut nicht AS_TRANS ist, dann:

• das AS4_AGGREGATOR-Attribut und das AS4_PATH-Attribut SOLLEN (SHALL) ignoriert werden,
• das AGGREGATOR-Attribut SOLL (SHALL) als die Information über den aggregierenden Knoten genommen werden, und
• das AS_PATH-Attribut SOLL (SHALL) als die AS-Pfadinformationen genommen werden.

Andernfalls,

• das AGGREGATOR-Attribut SOLL (SHALL) ignoriert werden,
• das AS4_AGGREGATOR-Attribut SOLL (SHALL) als die Information über den aggregierenden Knoten genommen werden, und
• die AS-Pfadinformationen müssen konstruiert werden, wie in allen anderen Fällen.

Um die AS-Pfadinformationen zu konstruieren, ist es notwendig, zuerst die Anzahl der AS-Nummern in den AS_PATH- und AS4_PATH-Attributen mit der in Abschnitt 9.1.2.2 von [RFC4271] und in [RFC5065] für die Routenauswahl spezifizierten Methode zu berechnen.

Wenn die Anzahl der AS-Nummern im AS_PATH-Attribut kleiner ist als die Anzahl der AS-Nummern im AS4_PATH-Attribut, dann SOLL (SHALL) das AS4_PATH-Attribut ignoriert werden, und das AS_PATH-Attribut SOLL (SHALL) als die AS-Pfadinformationen genommen werden.

Wenn die Anzahl der AS-Nummern im AS_PATH-Attribut größer oder gleich der Anzahl der AS-Nummern im AS4_PATH-Attribut ist, dann SOLLEN (SHALL) die AS-Pfadinformationen konstruiert werden, indem so viele AS-Nummern und Pfadsegmente wie nötig vom führenden Teil des AS_PATH-Attributs genommen und dann dem AS4_PATH-Attribut vorangestellt werden, sodass die AS-Pfadinformationen eine Anzahl von AS-Nummern haben, die mit der des AS_PATH-Attributs identisch ist. Beachten Sie, dass ein gültiges AS_CONFED_SEQUENCE- oder AS_CONFED_SET-Pfadsegment vorangestellt werden SOLL (SHALL), wenn es entweder das führende Pfadsegment ist oder an ein Pfadsegment angrenzt, das vorangestellt wird.