Zusammenfassung

  • RFC 3919 gab RMON-2-Agenten gemeinsame Namen für IPv6- und MPLS-Dekodierpfade, machte daraus aber keine Beschreibung jedes darüber transportierten Dienstes.
  • Die deutlichste Grenze steht in den MPLS-Einträgen selbst: Unicast und Multicast lassen sich am Einstieg unterscheiden, ihre untergeordneten Protokolle seien jedoch „nicht systematisch identifizierbar“.

Fernüberwachung beginnt mit einer scheinbar kleinen Frage: Welche Pakettypen kann eine Sonde erkennen? Das RMON-2-Protokollverzeichnis beantwortete sie als Inventar der Fähigkeiten eines Agenten. So ließen sich Zähler sowie Host- und Gesprächsstatistiken einem benannten Kapselungspfad zuordnen. Das Verzeichnis war weder eine universelle Paketerhebung noch ein Mechanismus, mit dem ein Agent durch das Hinzufügen einer Zeile einen neuen Decoder erlernte. RFC 2021 nennt dies begrenzte Erweiterbarkeit: Die Software muss die relevante Demultiplex-Logik bereits kennen, ehe sich die Dekodierung per Konfiguration um eine Ebene erweitern lässt.

RFC 3919 erschien im Oktober 2004 als Informational Memo und ergänzte Kennungsmakros für IPv6 und MPLS. Sein Ziel war eng umrissen: die Interoperabilität zwischen RMON-2-Agenten zu verbessern. Beschreiben verschiedene Sonden denselben Paketpfad mit unvereinbaren Namen, können Managementwerkzeuge ihre Protokollansichten kaum verlässlich vergleichen. Das Memo sagt ausdrücklich, dass eine RMON-2-konforme Implementierung ohne diese Kennungen möglich ist. Sie sind gemeinsamer Wortschatz, weder neue Konformitätsprüfung noch Beleg dafür, dass jede Sonde sie unterstützt. (RFC 3919; RFC-Editor-Eintrag)

Der Kontrast innerhalb des Dokuments ist aufschlussreich. Bei IPv6 bestimmt das ein Oktett breite Protocol-Feld das Folgeprotokoll. Die Kennung kann diesem bekannten Demultiplex-Wert folgen: RFC 3919 nennt ICMPv6 mit der Nummer 58 und unterscheidet UDP über natives IPv6 von UDP in einem IPv6-in-IPv4-Tunnel. ether2.ip6.udp und ether2.ip.ipip6.udp sind keine austauschbaren Etiketten. Der Pfad hält fest, welche Kapselungen der Decoder durchlaufen hat – nicht nur, dass am Ende UDP steht.

Bei MPLS endet der Zweig früher. RFC 3919 definiert mplsu und mplsm und unterscheidet Unicast und Multicast anhand der EtherTypes 0x8847 und 0x8848; auch Kodierungen für weitere Link-Layer werden genannt. Danach enden beide Einträge: Untergeordnete MPLS-Protokolle sind nicht systematisch identifizierbar. Das heißt weder, dass MPLS nie IP transportiert, noch dass Pakete hinter Labels grundsätzlich nicht dekodiert werden können. Die engere Aussage lautet: Dieses Kennungsset definiert unter den MPLS-Einträgen keinen allgemeinen, gemeinsam verwendbaren Protokollbaum. (RFC 3032)

Diese Grenze verhindert, dass ein Verzeichniseintrag mehr verspricht, als er beschreibt. Eine Sonde kann äußere Rahmung oder einen MPLS-Einstieg kennen, ohne für jede Nutzlast oder jeden Dienst hinter dem Label-Stack einen stabilen, gemeinsamen Namen auszugeben. Ein Routing-Label ist keine Protokollfamilien-Deklaration; seine Deutung hängt von anderen Mechanismen und Kontext ab. RFC 3919 leitet diesen Kontext nicht aus dem Label ab und behauptet auch nicht, dass verschiedene Agenten derselben Zeile dieselbe lokale Nummer geben.

Ebenso wichtig ist die Trennung zwischen Protokollname und Index. RFC 2895 definiert die Kodierung von protocolDirID und seinen Parametern. Zähltabellen verwenden dagegen protocolDirLocalIndex. Laut RFC 2021 ist dieser Integer nur innerhalb einer bestimmten SNMP-Entität aussagekräftig. Er ist ein lokaler Verweis auf das Verzeichnis der Sonde, keine globale Kennung, die sich in die Daten einer anderen Sonde kopieren lässt und dort garantiert dasselbe meint. Interoperabilität beruht auf gemeinsamen Beschreibungsregeln und ihrer sorgfältigen Auslegung – nicht auf identischen lokalen Nummern.

RFC 3919 zeigt somit eine kleine, aber wichtige Grenze. Wo IPv6 einen standardisierten Wert für das Folgeprotokoll bereitstellt, kann das Kennungsvokabular einen tieferen Dekodierpfad beschreiben. Wo es für MPLS-Unterprotokolle keine vergleichbare systematische Zuordnung gibt, endet die Beschreibung am äußeren Einstieg. Ein Fähigkeitsinventar hilft dem Management, bessere Fragen zu stellen; es beweist nicht, dass eine Sonde ein Paket tatsächlich gesehen, korrekt dekodiert, in einem Intervall gezählt oder den kommerziellen Dienst hinter einem Label erkannt hat.

Dafür braucht es Beobachtungsdaten und weitere Belege, nicht einen längeren Tabellennamen.

Quellen