Zusammenfassung

  • RFC 9508 unterscheidet drei Echo-Reply-Gründe: exakte Übereinstimmung mit einem administrativen Forwarder-Namen, Präfixbedienung durch eine lokale Anwendung oder ein exakt benanntes Objekt im Content Store.
  • Ein 64-Bit-Nonce verhindert PIT-Aggregation und bindet die Antwort an eine Anfrage. Frischevorgaben verhindern alte Diagnoseantworten, bestätigen aber nicht die Aktualität des gefundenen Objekts.
  • Die Signatur bindet den angegebenen Antwortnamen an einen akzeptierten Schlüssel; Produzentenbefugnis, Objektprovenienz, normale Auslieferung und Nutzerergebnis bleiben eigene Belege.

Hinter einem Namen liegen drei Haltepunkte

IP-Ping prägt das Bild von Adresse und Endpunkt. ICN leitet Interests anhand hierarchischer Namen weiter. Eine Anfrage kann beim Produzenten, bei einer lokal angebundenen Anwendung oder bei einer Kopie im Netz enden. Der Name legt keinen einzigen physischen Antwortort fest.

RFC 9508 hält den Grund im Echo Reply Code fest. T_ECHO_RETURN_FORWARDER bedeutet exakte Übereinstimmung mit einem administrativen Namen des Forwarders. T_ECHO_RETURN_APPLICATION bedeutet, dass Longest Name Prefix Match eine Face zu einer lokalen Anwendung fand. T_ECHO_RETURN_OBJECT bedeutet exakte Übereinstimmung mit einem Content Object im Store des Forwarders.

Der erste Beleg sagt, dass ein Weiterleitungselement für den eigenen Namen antwortete. Der zweite sagt, dass eine lokale Präfix-Anwendungs-Zuordnung existierte. Der dritte sagt, dass eine Kopie in diesem Knoten lag. Keiner beweist allein, dass der ursprüngliche Produzent läuft, die Anwendung eine normale Anfrage verarbeitet, die Kopie die gewünschte Version trägt oder der Leser nutzbaren Inhalt erhält.

Ein Dashboard muss deshalb Antwortcode und Antwortnamen vor dem Gesamtstatus anzeigen. Ein einziges Grün lässt sonst den Cache für die Origin, die Präfixzuordnung für die Ausführung und den Gerätenamen für die Lieferung sprechen.

Das Nonce isoliert den Versuch, nicht die Autorität

Interests mit gleichem Namen können einen Pending-Interest-Table-Eintrag teilen. Das spart Ressourcen, verändert aber die Messung: Eine spätere Anfrage nutzt gegebenenfalls Zustand der früheren. RFC 9508 hängt ein 64-Bit-Nonce an den Diagnosenamen, verhindert Aggregation und ordnet eine Antwort genau einer Anfrage zu.

Bei der Content-Store-Prüfung werden Nonce und Ping-Suffix entfernt. Die Transaktion bleibt eindeutig, das geprüfte Objekt behält seinen Basisnamen. Ein Object Reply bestätigt daher, dass diese unterscheidbare Anfrage in diesem Knoten eine Kopie dieses Basisnamens fand.

Die Herkunft der Kopie ist damit nicht vollständig belegt. Das Objekt besitzt Produzentensignatur, Version, Frische und Vertrauensregel. Die Forwarder-Signatur bestätigt den Bericht über den Hit, nicht die Urheberschaft. Basisname, Nonce, Code, Antwortender, Objektkennung oder Digest und Objektprüfung gehören gemeinsam in das Protokoll.

Nicht-Aggregation erhöht außerdem PIT-Zustand. Ein aggressiver Test kann selbst zur Erschöpfung beitragen. Rate, Lifetime, parallele Anfragen, Timeout und PIT-Belegung sind Teil des Messbelegs.

Eine frische Antwort kann eine alte Kopie melden

CCNx setzt ExpiryTime der Echo Reply auf null. NDN nutzt MustBeFresh für die Anfrage und FreshnessPeriod eins für die Antwort. Dadurch wird das Diagnosepaket fast sofort stale und kann nicht später als aktuelle Beobachtung wiederverwendet werden.

Diese Frische betrifft die Aussage über den Hit. Sie verjüngt das Content Object nicht. Eine heute korrekt signierte Mitteilung „X liegt hier“ kann sich auf eine Version beziehen, die der Dienst ersetzt hat oder deren Produzentenschlüssel nicht mehr verwendet wird.

Während einer Origin-Störung kann der Cache Leser weiter bedienen. Für Kontinuität ist das Erfolg, für einen Origin-Health-Check der falsche Antworttyp. Die Richtlinie muss vorab festlegen, ob Object Reply lokale Verfügbarkeit, Application Reply lokale Bedienung und welcher separate Canary die Origin oder tatsächliche Lieferung bestätigt.

Auch Schweigen ist keine eindeutige Origin-Diagnose. No Route, Verlust, Policy-Drop, Signaturfehler, Mappingfehler und Ablauf benötigen verschiedene Reaktionen.

Die Signatur authentisiert den Sprecher

Eine CCNx Echo Reply enthält Sendername und dessen Signatur; NDN Data trägt die Signatur des Antwortproduzenten. Der informative Clientablauf sieht vor, den Forwarder-Schlüssel zu beschaffen und Nachricht sowie enthaltenen Namen zu prüfen.

Das verhindert eine konkrete Substitution. Ein kompromittierter Forwarder könnte sonst den Namen eines Opfers einsetzen und spätere administrative Kommunikation zu ihm lenken. Die Signatur bindet den Namen an den Schlüssel unter der gewählten Vertrauensregel.

Sie beantwortet nicht, wer den Schlüssel für den administrativen Namen autorisierte, ob das Trust Schema aktuell ist, ob die Anwendung für das Präfix sprechen darf, wer das Cacheobjekt signierte oder ob Schlüssel rotiert wurden. Kryptographische Gültigkeit ist Beleg einer Aussage, kein universelles Mandat.

Der Mindestnachweis umfasst Antwortnamen, Schlüsselkennung oder Fingerprint, Trust-Regel, Prüfergebnis, Zeitpunkt und Reply Code. „Signatur gültig“ ohne Antwortklasse ist weiterhin mehrdeutig.

Diagnosepfad und normale Lieferung sind verschieden

Echo Reply folgt dem Rückwärtszustand der PIT. Ein Path Label nach RFC 9531 kann hopweise aktualisiert und für spätere Pings zu einem ähnlichen Zweig wiederverwendet werden; ohne Label lassen sich andere Zweige erkunden. Das verbessert Wiederholbarkeit, beweist aber nicht alle Pfade.

RFC 9507 besitzt ICN Traceroute mit aufeinanderfolgenden HopLimits und Routenvielfalt. RFC 9508 fragt enger: Welche Art von Instanz beantwortete diesen Ping? Ein lokaler Antwortgrund darf nicht zur vollständigen Pfadbeschreibung werden.

Eine normale Interest kann aggregiert werden, kein Ping-Suffix tragen, andere Parameter und Strategien nutzen und einen anderen Cache wählen. Wenn das Versprechen Lieferung heißt, muss nach dem Ping ein normaler Abruf folgen. Objektname oder Digest, Produzentensignatur, Version, Anwendungsannahme und Lesergebnis sind separat zu prüfen.

Lokale Namen brauchen Mapping-Verantwortung

Für nur regional routbare Namen beschreibt RFC 9508 ein signiertes Link Object mit routbaren Präfixen oder ein vorangestelltes Präfix, das der Border Forwarder entfernt und für die Antwort wiederherstellt.

Wie der Client das Link Object erhält, bleibt außerhalb des Dokuments. Umschreiben setzt voraus, dass die Grenze die Nachbarregion kennt und den restlichen Namen intern als routbar erkennt. Mehrere Regionen und Präfixe vergrößern den Rückzustand.

Mappingobjekt oder Regel, Signierer, Gültigkeit, Border, Name vor und nach der Änderung sowie Rückwiederherstellung sind zu speichern. Eine Antwort belegt eine ausgeführte Kette, nicht jede Alternative.

Quellen