Anhang A: Semantik und Verwendung des Flow-Label-Feldes

Ein Fluss (flow) ist eine Sequenz von Paketen, die von einer bestimmten Quelle an ein bestimmtes (Unicast- oder Multicast-)Ziel gesendet werden und für die die Quelle eine besondere Behandlung durch die Zwischenrouter wünscht. Die Art dieser besonderen Behandlung kann den Routern durch Steuerprotokolle (wie Ressourcenreservierungsprotokolle) oder durch Informationen in den Paketen des Flusses selbst (z. B. in Hop-by-Hop-Optionen) mitgeteilt werden. Die Details solcher Steuerprotokolle oder Optionen liegen außerhalb des Geltungsbereichs dieses Dokuments.

Von einer Quelle zu einem Ziel können mehrere aktive Flüsse gleichzeitig vorhanden sein, sowie Datenverkehr, der keinem Fluss zugeordnet ist. Ein Fluss wird durch die Kombination aus Quelladresse und einem Nicht-Null-Flusslabel eindeutig identifiziert. Pakete, die nicht zu einem Fluss gehören, tragen das Flusslabel null.

Flusslabels werden von den Quellknoten der Flüsse zugewiesen. Neue Flusslabels MÜSSEN (pseudo-)zufällig und gleichmäßig aus dem Bereich 1 bis FFFFF hexadezimal ausgewählt werden. Der Zweck der zufälligen Zuweisung besteht darin, dass jede Teilmenge von Bits im Flow Label-Feld als Hash-Schlüssel für Router geeignet ist, um den mit dem Fluss verbundenen Zustand nachzuschlagen.

Alle Pakete, die zu demselben Fluss gehören, MÜSSEN mit derselben Quelladresse, Zieladresse und demselben Flusslabel gesendet werden. Wenn eines dieser Pakete einen Hop-by-Hop Options Header enthält, MÜSSEN alle mit demselben Hop-by-Hop Options Header-Inhalt initiiert werden (mit Ausnahme des Next Header-Feldes des Hop-by-Hop Options Headers). Wenn eines dieser Pakete einen Routing Header enthält, MÜSSEN alle mit demselben Inhalt in allen Erweiterungsheadern bis einschließlich des Routing Headers initiiert werden (mit Ausnahme des Next Header-Feldes im Routing Header). Router oder Ziele DÜRFEN, sind aber nicht verpflichtet, zu überprüfen, ob diese Bedingungen erfüllt sind. Wenn eine Verletzung erkannt wird, SOLLTE sie der Quelle über eine ICMP-Parameter-Problem-Nachricht (Code 0, zeigt auf das höchstwertige Oktett des Flow Label-Feldes, d. h. Offset 1 innerhalb des IPv6-Pakets) gemeldet werden.

Die maximale Lebensdauer jedes Flusszustandszustands, der entlang des Flusspfades eingerichtet wird, MUSS als Teil der Beschreibung des Zustandseinrichtungsmechanismus (z. B. Ressourcenreservierungsprotokoll oder Flusseinrichtungs-Hop-by-Hop-Option) angegeben werden. Eine Quelle DARF NICHT ein Flusslabel für einen neuen Fluss innerhalb der maximalen Lebensdauer eines Flusszustandszustands wiederverwenden, der möglicherweise für eine frühere Verwendung dieses Flusslabels eingerichtet wurde.

Wenn ein Knoten stoppt und neu startet (z. B. aufgrund eines „Absturzes (crash)"), MUSS er darauf achten, keine Flusslabels zu verwenden, die möglicherweise für frühere Flüsse verwendet wurden, deren Lebensdauer möglicherweise noch nicht abgelaufen ist. Dies kann erreicht werden, indem die Flusslabelverwendung in stabilem Speicher aufgezeichnet wird, damit sie nach einem Absturz erinnert werden kann, oder indem die Verwendung von Flusslabels vermieden wird, bis die maximale Lebensdauer aller möglicherweise zuvor eingerichteten Flüsse abgelaufen ist. Wenn die Mindestneustartzeit des Knotens bekannt ist, kann diese Zeit von der erforderlichen Wartezeit abgezogen werden, bevor mit der Zuweisung von Flusslabels begonnen wird.

Es ist nicht erforderlich, dass alle oder sogar die meisten Pakete zu einem Fluss gehören, d. h. ein Nicht-Null-Flusslabel tragen. Diese Beobachtung wird hier eingefügt, um Protokolldesigner und Implementierer daran zu erinnern, keine anderen Annahmen zu treffen. Es wäre beispielsweise unklug, einen Router zu entwerfen, dessen Leistung nur dann ausreichend ist, wenn die meisten Pakete zu Flüssen gehören, oder ein Header-Komprimierungsschema zu entwerfen, das nur für Pakete funktioniert, die zu Flüssen gehören.