Zusammenfassung

  • RFC 5420 verlagert die RSVP-TE-Attributerweiterung vom acht Bit breiten SESSION_ATTRIBUTE-Flags-Feld in TLVs, weil dieses Feld fortlaufende Erweiterungen nicht aufnehmen konnte. Die Erweiterungen gelten für MPLS und GMPLS sowie für Paket- und Nichtpaket-LSPs.
  • Das Attribute Flags TLV kann in LSP_ATTRIBUTES oder in LSP_REQUIRED_ATTRIBUTES vorkommen. Der TLV oder ein Bit macht ein Attribut jedoch nicht selbst verpflichtend. Das Trägerobjekt bestimmt, ob transparente Weiterleitung oder eine pfadweite erforderliche Prüfung gilt.
  • Die drei Gegenfakten sind ausdrücklich: Ein unbekannter TLV oder ein unbekanntes Bit in LSP_ATTRIBUTES wird unverändert weitergeleitet; ein unbekanntes Objekt, ein unbekannter TLV oder ein unbekannt gesetztes Bit in LSP_REQUIRED_ATTRIBUTES weist den Setup zurück; ein erkanntes, aber nicht unterstütztes Attribut folgt dem RFC, der es definiert, nicht einer Universalregel.
  • Der Requester wählt die Durchsetzungsgrenze. Jeder Transit-LSR darf nach Objekt und definierendem RFC erkennen und ablehnen; akzeptierter Inhalt wird anschließend zur nächsten Station weitergeleitet. Erfolgreicher optionaler Aufbau beweist deshalb keine Anwendung.

Zuständigkeit statt Pauschalregel

LSP_ATTRIBUTES der Klasse 197 und in C-Num-Form steht für optionale oder selektive Weitergabe. Ein LSR, das das Objekt nicht unterstützt, leitet es unverändert weiter. Ein unbekannter TLV-Typ oder ein unbekanntes gesetztes Attributbit wird darin ebenfalls unverändert weitergeleitet. LSP_REQUIRED_ATTRIBUTES der Klasse 67 verlangt dagegen, dass jeder Transit-LSR den Inhalt untersucht und entsprechend handelt. Erkennt ein LSR das Objekt, den TLV-Typ oder ein gesetztes Bit nicht, weist es den Setup per PathErr mit Unknown Attributes TLV beziehungsweise Unknown Attributes Bit zurück.

Diese Regeln bilden keine allgemeine Antwort auf jedes erkannte, aber nicht unterstützte Attribut. Der definierende RFC bleibt dafür maßgeblich. Der Requester kann über das Trägerobjekt eine Untersuchung auf dem gesamten Pfad verlangen, aber er kann nicht aus dem Wort „required“ eine einheitliche Unsupported-Reaktion ableiten. Der Transit-LSR hat Erkennungs- und gegebenenfalls Zurückweisungskompetenz, jedoch keine Erlaubnis, eine neue Semantik zu erfinden. Nach einer akzeptierten Prüfung wird der Inhalt getrennt davon an den nächsten Transit-LSR weitergeleitet.

Bei egress-only genügt möglicherweise eine Prüfung oder Meldung am Ausgang. Bei key-transit liegt die Abhängigkeit an einer bestimmten Transitposition. Bei all-LSR wird die Fähigkeit jedes Transit-LSR zur Setup-Bedingung. Begünstigt werden Dienste, deren tatsächliche Abhängigkeit zur gewählten Grenze passt. Die RFCs belegen dagegen weder bestimmte Anbieter, Implementierungen noch Verbreitung.

LSP_REQUIRED_ATTRIBUTES wird nicht in Resv verwendet. LSP_ATTRIBUTES in Resv kann den Status des gesamten LSP melden; der RRO-Attributes-Subobject meldet hop-spezifischen Status. Er ist an die unmittelbar vorhergehende Adresse oder das Interface im RRO gebunden, und ein Node darf ihn nicht ohne diesen Identifikator einfügen. Compliance oder Nicht-Compliance darf nur dort gemeldet werden, wo der definierende RFC die Bedeutung vorsieht. Ein erfolgreicher Aufbau ist kein impliziter Nachweis.

Per-Hop-Reporting hat einen Preis: Es kann operative Zustände wie erkannte Unterstützung, Nicht-Compliance oder lokale Politik offenlegen und verbraucht RRO- sowie Path-/Resv-Nachrichtenraum. Wird RRO dadurch zu groß, greifen die Oversized-RRO-Regeln von RFC 3209. Whole-LSP-Status in Resv und hop-spezifische Meldung im RRO sind deshalb getrennt zu bewerten.

An einer LSP-Regionsgrenze kann ein Forwarding-Adjacency-LSP unter lokaler Policy eine Teilmenge der Attribute-TLVs erben, wenn die Grenze die relevanten Objekte unterstützt. Andernfalls werden die Attributobjekte mit dem geerbten ERO kopiert. RFC 5420 verwendet für Attribute Flags TLV und RRO Attributes einen gemeinsamen, von IANA verwalteten Bitnummernraum; der definierende RFC muss Bedeutung und Nullstandard angeben.

RFC 7570 ist eine spätere generische Erweiterung der RFC-5420-Mechanik und der Registrierungshinweise für RSVP-TE-Attribut-TLVs sowie hop-spezifische Attribute in ERO und RRO. Sie ist kein Beleg für universelle Bereitstellung und keine speziell auf Schutzmechanismen beschränkte Funktion. Die verlinkte Errata-Seite ist der eingefrorene RFC-5420-Errata-Stand; daraus wird hier keine einzelne Korrekturbehauptung abgeleitet.

Konkrete Verifikations-Fixtures

  1. Sende einen Path mit unbekanntem TLV oder Bit in LSP_ATTRIBUTES durch einen Legacy-LSR. Prüfe unveränderte Weiterleitung, aber nicht die Anwendung des Attributs.
  2. Sende denselben Inhalt in LSP_REQUIRED_ATTRIBUTES. Prüfe PathErr, den passenden Unknown Attributes TLV und das Ausbleiben des LSP-Aufbaus.
  3. Setze ein unbekanntes Bit im erforderlichen Objekt und prüfe Unknown Attributes Bit. Wiederhole den Test mit einem bekannten, nicht unterstützten Attribut und dokumentiere die vom definierenden RFC verlangte Reaktion.
  4. Prüfe Resv auf den Whole-LSP-Status und RRO auf Hop-Status. Füge den RRO-Attributes-Subobject nur direkt nach dem zugehörigen Identifikator ein und erfasse Reporting-Kosten und Nachrichtenraum.
  5. Teste eine FA-LSP-Regionsgrenze mit teilweiser lokaler Vererbung und behandle RFC 7570 als generische Hop-Attribut-Erweiterung, nicht als Nachweis allgemeiner Einführung oder als Schutzmechanismus.

Nicht belegt sind Anbieter, konkrete Deployments, Vorfälle, Verbreitung, Fehlerraten, Setup-Latenz, Performance, kommerzielle Werte oder Kundenergebnisse. Ebenso legt der Quellensatz nicht fest, welche künftigen Attribute optional, erforderlich, egress-only oder key-transit sein sollen; das bestimmen definierender RFC und Betreiberpolicy.

Quellen