9. Manageability Considerations (Verwaltbarkeitsüberlegungen)
9. Manageability Considerations (Verwaltbarkeitsüberlegungen)
In SR-fähigen Netzwerken ist der Pfad, den das Paket nimmt, im Header kodiert. Da der Pfad nicht über ein Protokoll signalisiert wird, sind OAM-Mechanismen erforderlich, damit der Netzwerkbetreiber die Wirksamkeit eines Pfades validieren sowie seine Lebendigkeit und Leistung überprüfen und überwachen kann. Es ist jedoch zu beachten, dass SR die Anzahl der Zustände in Transitknoten erheblich reduzieren kann; daher ist die Anzahl der Elemente, die ein Transitknoten verwalten muss, kleiner.
SR-OAM-Anwendungsfälle für die MPLS-Datenebene sind in [RFC8403] definiert. SR-OAM-Verfahren für die MPLS-Datenebene sind in [RFC8287] definiert.
SR-Router empfangen Ankündigungen von SIDs (Index, Label oder IPv6-Adresse) von den verschiedenen Routing-Protokollen, die für SR erweitert werden. Jedes dieser Protokolle verfügt über Überwachungs- und Fehlerbehebungsmechanismen, um Betriebs- und Verwaltungsfunktionen für IP-Adressen bereitzustellen, die erweitert werden müssen, um Fehlerbehebungs- und Überwachungsfunktionen für die SID einzuschließen.
Die SR-Architektur führt die Verwendung globaler Segmente ein. Jedes globale Segment MUSS an einen eindeutigen Index oder eine eindeutige Adresse innerhalb einer SR-Domäne gebunden sein. Die Verwaltung der Zuweisung eines solchen Index oder einer solchen Adresse durch den Betreiber ist für das Netzwerkverhalten kritisch, um Situationen wie Fehlrouting zu vermeiden. Zusätzlich zur Zuweisungsrichtlinie/zum Tooling, das der Betreiber eingerichtet hat, SOLLTE eine Implementierung das Netzwerk im Falle einer Konflikterkennung schützen, indem sie einen deterministischen Lösungsansatz bereitstellt.
Wenn ein Pfad unter Verwendung eines Label-Stacks ausgedrückt wird, wird das Auftreten von Label-Stacking zunehmen. Ein Knoten möchte möglicherweise in der Control-Plane seine Fähigkeit in Bezug auf die Größe des Label-Stacks signalisieren, den er unterstützen kann.
Ein YANG-Datenmodell [RFC6020] für SR-Konfiguration und -Betrieb wurde in [SR-YANG] definiert.
Wenn SR auf die IPv6-Datenebene angewendet wird, werden Segmente durch IPv6-Adressen identifiziert. Die Zuweisung, Verwaltung und Fehlerbehebung von Segment-Identifikatoren unterscheidet sich nicht von den bestehenden Mechanismen, die für die Zuweisung und Verwaltung von IPv6-Adressen angewendet werden.
Die DA des Pakets gibt die aktive Segmentadresse an. Die Segmentliste im SRH gibt den gesamten Pfad des Pakets an. Die Validierung des quellengerouteten Pfades erfolgt durch Inspektion der im Paket-Header vorhandenen DA und SRH, die mit den entsprechenden Routing-Tabelleneinträgen abgeglichen werden.
Im Kontext der SRv6-Datenebene ist der quellengeroutete Pfad im SRH kodiert, wie in [IPv6-SRH] beschrieben. Der SRv6-quellengeroutete Pfad wird als Liste von IPv6-Adressen im SRH instanziiert, wobei sich das aktive Segment im DA-Feld des IPv6-Paket-Headers befindet. Typischerweise ist es durch Inspektion des Paket-Headers in einem beliebigen Knoten möglich, den quellengerouteten Pfad abzuleiten, zu dem er gehört. Ähnlich wie im Kontext der SR-MPLS-Datenebene kann eine Implementierung Pfadkontroll- und Überwachungspakete erzeugen, bei denen der quellengeroutete Pfad in den SRH eingefügt wird und jedes Segment des Pfades die relevanten Daten in das Paket einfügt, um den End-zu-End-Pfad und die Leistung zu messen.