4. Grouping packets into packet streams (Pakete in Paketströme gruppieren)
4. Grouping packets into packet streams (Pakete in Paketströme gruppieren)
Dieser Abschnitt erläutert, wie Pakete zur Komprimierung in Paketströme zusammengefasst werden. Um eine optimale Komprimierungsrate zu erzielen, SOLLTEN Pakete so zusammengefasst werden, dass Pakete im selben Paketstrom ähnliche Header haben. Wenn diese Gruppierung fehlschlägt, ist die Header-Komprimierungsleistung schlecht, da der Komprimierungsalgorithmus selten den vorhandenen Kontext eines Paketstroms nutzen kann und häufig vollständige Header senden muss.
Die Gruppierung wird vom Kompressor durchgeführt. Der Kompressor KANN beliebige Kriterien verwenden, um Pakete in Paketströme zu gruppieren. Um zu bestimmen, zu welchem Paketstrom ein Paket gehört, KANN der Kompressor:
a) die komprimierbare Teilheader-Kette untersuchen (siehe Abschnitt 7),
b) den Inhalt der Protokoll-Header der oberen Schicht untersuchen, die der komprimierbaren Teilheader-Kette folgen, z. B. ICMP-Header, DVMRP-Header oder getunnelte IPX-Header,
c) Informationen verwenden, die von einem Ressourcenmanager erhalten wurden, z. B. wenn ein Ressourcenmanager die Komprimierung eines bestimmten Paketstroms anfordert und eine Möglichkeit zur Identifizierung von Paketen bereitstellt, die zu diesem Paketstrom gehören,
d) andere relevante Informationen verwenden, z. B. wenn Routing-Instabilität vorliegt und das Hop-Limit-Feld (TTL) im Paketstrom häufig zwischen n und n+k wechselt, KANN der Kompressor wählen, Pakete in zwei verschiedene Paketströme zu gruppieren.
Der Kompressor KANN auch darauf verzichten, Pakete zur Komprimierung in Paketströme zu gruppieren, und einige Pakete mit ihren regulären Headern unverändert weiterleiten.
Solange die Regeln für das Senden vollständiger Header für Nicht-TCP-Paketströme eingehalten werden und Teilheader wie in diesem Dokument beschrieben komprimiert werden, ist der Dekompressor in der Lage, komprimierte Header korrekt zu rekonstruieren, unabhängig davon, wie Pakete in Paketströme gruppiert werden.
4.1 Guidelines for grouping packets (Richtlinien für die Paketgruppierung)
In diesem Abschnitt geben wir optionale Richtlinien dazu, wie der Kompressor Pakete zur Komprimierung in Paketströme gruppieren KANN.
Defining fields (Definitionsfelder)
Die Definitionsfelder eines Headers SOLLTEN in allen Paketen desselben Paketstroms vorhanden und identisch sein. Diese Felder sind in Abschnitt 7 als DEF markiert. Zu den Definitionsfeldern gehören das Flow-Label, die Quell- und Zieladressen des IP-Headers, die endgültige Zieladresse im Routing-Header, das Next-Header-Feld (für IPv6), das Protokollfeld (IPv4), Portnummern (UDP und TCP) sowie der SPI in Authentifizierungs- und Verschlüsselungs-Headern.
Fragmented packets (Fragmentierte Pakete)
Fragmentierte und nicht fragmentierte Pakete SOLLTEN NIEMALS im selben Paketstrom zusammengefasst werden. Das Identifikationsfeld des Fragmentierungs-Headers oder des IPv4-Headers SOLLTE NICHT zur Identifizierung von Paketströmen verwendet werden. Wenn dies der Fall ist, führt das erste Fragment eines neuen Pakets zu einem Komprimierungs-Slow-Start.
Felder nach einem Fragmentierungs-Header oder nach einem für die Fragmentierung verwendeten IPv4-Header SOLLTEN NICHT für Gruppierungszwecke verwendet werden.
Upper protocol identification (Identifizierung des oberen Protokolls)
Das erste Next-Header-Feld, das einen in Abschnitt 7 nicht beschriebenen Header identifiziert, SOLLTE zur Identifizierung von Paketströmen verwendet werden, d. h. alle Pakete mit denselben DEF-Feldern und demselben oberen Protokoll SOLLTEN zusammengefasst werden.
TTL field (Hop Limit field) (TTL-Feld / Hop-Limit-Feld)
Komplexe Implementierungen KÖNNEN das TTL-Feld (Hop Limit) überwachen und es als DEF-Feld verwenden, wenn es sich häufig ändert. Dies kann bei häufiger Routing-Instabilität auftreten, sodass Pakete unterschiedliche Pfade durch das Internet nehmen.
Traffic Class field (IPv6), Type of Service field (IPv4) (Traffic-Class-Feld (IPv6), Type-of-Service-Feld (IPv4))
Das Traffic-Class-Feld des IPv6-Headers und der Type-of-Service-Wert des IPv4-Headers können sich zwischen Paketen mit denselben DEF-Feldern häufig ändern. Komplexe Implementierungen SOLLTEN dies berücksichtigen und bereit sein, diese Felder als Definitionsfelder zu verwenden.
Wenn IP-Pakete getunnelt werden, werden sie am Tunneleintrittspunkt mit einem zusätzlichen IP-Header gekapselt und dann an den Tunnelendpunkt gesendet. Um solche Pakete in Paketströme zu gruppieren, SOLLTEN auch die inneren Header untersucht werden, um den Paketstrom zu bestimmen. Andernfalls wird jedes Mal ein vollständiger Header gesendet, wenn sich der Header des inneren IP-Pakets ändert. Daher SOLLTEN bei getunnelten Paketen zusätzlich zu den Identifizierungsfeldern des anfänglichen IP-Headers auch die Identifizierungsfelder der inneren Teilheader berücksichtigt werden.
Implementierungen KÖNNEN andere als die hier beschriebenen Felder zur Identifizierung verwenden. Wenn zu viele Felder zur Identifizierung verwendet werden, kann die Leistung leiden, da mehr CIDs verwendet werden und beim Bedarf einer neuen CID möglicherweise die falsche CID wiederverwendet wird. Wenn zu wenige Felder zur Identifizierung verwendet werden, kann die Leistung leiden, da Kontextänderungen zu häufig auftreten.
Wir betonen, dass diese Richtlinien fundierte Vermutungen sind. Wenn IPv6 weit verbreitet ist und IPv6-Datenverkehr analysiert werden kann, könnten wir feststellen, dass andere Gruppierungsalgorithmen besser abschneiden. Wir betonen auch, dass wenn die Gruppierung fehlschlägt, das Ergebnis schlechte Leistung ist, aber keine fehlerhafte Dekomprimierung. Der Dekompressor kann seine Aufgabe erfüllen, unabhängig davon, wie der Gruppierungsalgorithmus funktioniert.