Zusammenfassung

  • RFC 7570 definiert optionale ERO-Hop-Attributes- und RRO-Hop-Attributes-Subobjects für Attribute, die mit einem bestimmten Hop verbunden sind. Das ERO-Subobject hat Typ 35, variable Länge und enthält ein oder mehrere Hop-Attributes-TLVs innerhalb seiner Subobject-Länge.
  • Das Subobject folgt einem identifizierenden ERO-Subobject oder den zu diesem Hop gehörenden Label-Subobjects. Seine Attribute gelten für das unmittelbar vorhergehende Subobject beziehungsweise die unmittelbar vorhergehenden Subobjects. Die Platzierung begrenzt also den Adressaten, verleiht aber keine Autorität über das gesamte LSP.
  • Das definierende Attributdokument muss zulässige vorhergehende ERO-Subobject-Typen, die Bedeutung einer möglichen Reihenfolge, Änderungsregeln und Anforderungen an die Berichterstattung festlegen. Das R-Bit ist nicht die Semantik des Attributs.

Im Paket sieht das so aus: Hop-identifizierendes ERO-Subobject, danach Typ 35 und darin das TLV des Attributs. Bei R=1 prüft der Knoten die TLVs nach den Required-Regeln aus RFC 5420, Abschnitt 5. Bei R=0 gelten die Optional-Regeln aus Abschnitt 4.2. Damit wird die Behandlung unbekannten Inhalts an diesem Hop gesteuert, nicht die Bedeutung des TLV erfunden. Platzierung, Reihenfolge, zulässige Änderung und Reporting kommen aus der definierenden Spezifikation sowie aus lokaler Policy und Autorisierung.

Ein Knoten kann die Anforderung wegen RSVP-Policy oder Admission Control ablehnen. Er darf ein Attribut ändern, wenn die TLV-Verfahren das erlauben. Unterstützt ein Knoten das ERO-Hop-Attributes-Subobject bei der Verarbeitung nicht, sieht RFC 7570 einen Routing Error / Bad EXPLICIT_ROUTE PathErr vor; das ERO wird bis zum beanstandeten Subobject gekürzt. Ein malformed oder sonst ungültiges Subobject wird durch R=0 nicht gültig. RFC 3209 behandelt ein unbekanntes ERO-Subobject, das bereits verarbeitet wird, als Bad Explicit Route Object; ein noch nicht erreichtes unbekanntes Subobject kann weitergereicht werden.

Bei Flags gelten nur die im ERO-Hop-Kontext als gültig definierten Flags: ungültige Flags werden still ignoriert, unbekannte Flags sollten einen Unknown Attributes Bit PathErr auslösen.

Whole-LSP-Reporting und Hop-Reporting sind getrennt. Attribute in LSP_ATTRIBUTES oder LSP_REQUIRED_ATTRIBUTES werden normalerweise über RFC-5420-RRO-Attributes berichtet. Ein Attribut, das nur in ERO-Hop-Attributes signalisiert wurde, wird normalerweise in RRO-Hop-Attributes berichtet; auch dieses Subobject hat Typ 35. Ein Knoten kann melden, dass er ein ERO-Attribut berücksichtigt hat, oder ein zusätzliches TLV zurückgeben. Ob daraus eine Compliance-Pflicht entsteht, bestimmt ausschließlich das definierende Attributdokument.

Transitknoten leiten RRO-Hop-Attributes normalerweise unverändert weiter, doch eine Domain-Grenze darf sie wegen Vertraulichkeit oder Nachrichtengröße entfernen oder verändern. Ein vorhandener RRO-Eintrag ist daher kein unveränderlicher Beweis; ein fehlender Eintrag beweist umgekehrt kein Scheitern.

RFC 7571 ist nur ein begrenztes Anwendungsbeispiel: Ein OAM-Loopback wird auf einen bestimmten Knoten gezielt, und der Zustand kann über RRO-Hop-Attributes berichtet werden. Das Beispiel macht Loopback nicht zur generischen Bedeutung des RFC-7570-Containers. Der Nutznießer einer hop-spezifischen Anforderung braucht Unterstützung und Zulassung genau an diesem Knoten; ein erfolgreich eingerichtetes LSP beweist bei optionaler Verarbeitung allein nicht, dass das Verhalten ausgeführt wurde.

Betreiber-Entscheidungsweg

  1. Bestimme Hop und unmittelbar vorhergehendes ERO-Subobject; prüfe Typ, Reihenfolge und Platzierung gegen das definierende Attributdokument.
  2. Prüfe lokale Autorisierung, Policy und Admission Control. Entscheide ausdrücklich, ob R=1 erforderlich ist oder R=0 mit begrenztem Nachweis genügt.
  3. Prüfe ERO-/Path-Länge, Flag-Regeln, mögliche Attributänderung und die RRO-Filterung an Domain-Grenzen.
  4. Vergleiche Path, PathErr und RRO. Werte erfolgreiches Setup ohne spezifikationsgemäßes RRO-Reporting nicht als optionalen Compliance-Beweis.

Konkrete Paketprüfungen

  • Fixture A: ERO für Knoten A, unmittelbar danach Typ 35 mit TLV und R=0. Prüfe, dass A der adressierte Hop ist und aus dem Paket keine Autorität oder Ausführung bei Knoten B folgt.
  • Fixture B: Sende Typ 35 mit R=1 an einen Knoten ohne Unterstützung. Erwartet werden Routing Error / Bad EXPLICIT_ROUTE PathErr und ein bis zum fehlerhaften Subobject gekürztes ERO.
  • Fixture C: Teste ein unzulässiges und ein unbekanntes Flag getrennt. Das erste wird still ignoriert; das zweite sollte Unknown Attributes Bit PathErr auslösen.
  • Fixture D: Stelle ein Whole-LSP-Attribut in RRO Attributes einem Hop-Attribut in RRO-Hop-Attributes gegenüber und entferne den RRO-Eintrag an einer Domain-Grenze. Das Ergebnis ist fehlender Nachweis, nicht automatisch Attributversagen.
  • Fixture E: Verwende einen nicht erlaubten vorhergehenden ERO-Typ oder eine verbotene Reihenfolge. Prüfe Ablehnung oder zulässige lokale Änderung; R ist keine Erlaubnis, die definierende Spezifikation zu umgehen.

Die Quellen belegen weder Anbieter- oder Betreiberimplementierungen noch Verbreitung, Fehlerraten, Messwerte zum Nachrichtenwachstum oder Kundenergebnisse. Es wird kein Vorfall und keine Einführung behauptet. Zur Errata-Lage wird nur die eingefrorene RFC-Editor-Suchseite herangezogen; eine weitergehende Korrekturbehauptung folgt daraus nicht.

Quellen