Zusammenfassung

  • RFC 5148 empfiehlt Zufallsvariation für MANET-Kontrollverkehr, wenn untere Schichten Kollisionen nicht wirksam vermeiden.
  • Periodische Erzeugung, externe Auslösung und Weiterleitung haben verschiedene Zeitregeln.
  • Periodische Nachrichten verkürzen ihr Intervall; ausgelöste und weitergeleitete Nachrichten warten.
  • Der Wert soll gleichverteilt zwischen null und MAXJITTER liegen.
  • Eine Konfiguration beweist weder reale Gleichverteilung noch unabhängige Zufallsquellen.
  • Periodischer Maximaljitter darf die Hälfte des Intervalls nicht überschreiten und sollte unter einem Viertel bleiben.
  • Ein positives Mindestintervall erzeugt weitere Grenzen.
  • Weiterleiter kennen das Ursprungsintervall möglicherweise nicht und brauchen eine protokollspezifische Regel.
  • Während des Wartens können neuere Ereignisse oder Nachrichten eintreffen.
  • Mehrere Nachrichten eines Pakets sollen denselben Zufallswert verwenden.
  • Verzögerung summiert sich über Hops und gehört in das Budget für den Netzdurchmesser.
  • Weniger Kollisionen beweisen weder Empfang, Konvergenz, Fairness noch Anwendungserfolg.

Der Zielkonflikt beginnt bei der Dichte

Gleiche Perioden, gemeinsame Ereignisse und sofortige Weiterleitung können benachbarte Router synchronisieren. Jitter bricht diese Wiederholung, sofern MAC und physische Schicht das Problem nicht bereits wirksam lösen. Diese Anwendungsgrenze verhindert, dass Verzögerung als bloßes Konformitätsmerkmal eingesetzt wird.

Eine größere Interferenznachbarschaft erhöht die Kollisionswahrscheinlichkeit und kann mehr Zufallsabstand rechtfertigen. Doch die RFC fordert zugleich, MAXJITTER so klein wie möglich zu halten, weil Verzögerung ein ansonsten gutes Protokoll beeinträchtigt.

Drei Zeitgesetze statt eines Schalters

Periodische Nachrichten folgen MESSAGE_INTERVAL - jitter, ausgehend von der letzten tatsächlichen Sendung. Extern ausgelöste Nachrichten werden verzögert; ein neu gestarteter periodischer Plan soll am verzögerten Zeitpunkt ansetzen. Weiterleitung fügt ebenfalls Wartezeit hinzu, aber der Zwischenknoten kennt das Intervall des Ursprungs möglicherweise nicht.

Vereinbarung, Übermittlung im Paket, Schätzung oder eine andere Protokollregel müssen diese Lücke schließen. Eine gemeinsame Anzeige „Jitter aktiv“ verschweigt, welches Gesetz angewendet wurde.

Schranken sind keine Laufzeitbelege

Der periodische Maximalwert muss nichtnegativ sein, darf MESSAGE_INTERVAL/2 nicht überschreiten und sollte höchstens ein Viertel betragen. Für ein positives MESSAGE_MIN_INTERVAL gelten dessen voller und halber Wert als Pflicht- beziehungsweise Empfehlungsgrenze. Der Zufallswert soll uniform gewählt werden.

MIB-Werte und Protokollvorgaben zeigen die beabsichtigte Steuerung. Sie beweisen nicht, dass der Generator aufgerufen wurde, nach einem Massenneustart unabhängige Seeds besaß oder die Queue den Wert respektierte. Dafür braucht es Laufzeitspuren.

Warten erzeugt Überholen

Während eine Nachricht wartet, kann ein neuer Trigger eintreffen. Bei aufgeschobener Erzeugung lassen sich Ereignisse zusammenfassen; bei bereits erzeugten Nachrichten muss das Protokoll verwerfen, beide senden oder die Reihenfolge erhalten. Gleiches gilt für eine neuere weiterzuleitende Nachricht.

Nachrichten aus einem empfangenen Paket sollen einen gemeinsamen Zufallswert erhalten. Mehrere Werte zu ziehen und das Minimum zu verwenden senkt systematisch den Mittelwert. Bei einer Zusammenführung aus verschiedenen Paketen kann die früheste unabhängige Frist den gemeinsamen Termin bestimmen.

Der Pfad multipliziert die Kosten

Weiterleitungsjitter fällt an jedem Hop an. RFC 5148 verlangt deshalb, erwartete Weiterleitungen bis zum Netzdurchmesser zu berücksichtigen. RFC 7181 trennt periodische, ausgelöste und weitergeleitete TC-Parameter; RFC 7183 rechnet Hop-Verzögerungen in Gültigkeitszeiten ein.

Eine längere Gültigkeit ist kein Empfangsnachweis. Konfiguration, Scheduler, Funksendung, Empfänger, Protokollverarbeitung, Topologie, Route und Datenverkehr bleiben getrennte Belege. Weniger vorhersagbare Zeitpunkte können selektives Stören erschweren, ersetzen aber weder Authentisierung noch umfassende Störfestigkeit.

Sources

  1. RFC 5148, HTML
  2. RFC 5148, Text
  3. RFC-Editor-Eintrag
  4. IETF Datatracker
  5. Historie
  6. Referenzen
  7. Errata
  8. RFC 6130
  9. RFC 7181
  10. RFC 7183
  11. RFC 7939
  12. RFC 7985
  13. RFC 5444
  14. RFC 3626
  15. RFC 3561
  16. RFC 4271
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy