DE60120793T2

DE60120793T2 - Verfahren und Kompressor zur Komprimierung von Zeitstempelinformation von Paketen

Info

Publication number: DE60120793T2
Application number: DE60120793T
Authority: DE
Inventors: David Irving LEON; Le Coppell KHIEM
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2000-09-28
Filing date: 2001-09-28
Publication date: 2006-10-05
Anticipated expiration: 2021-09-29
Also published as: EP1696672A2; AU2001296417A1; US20020083205A1; WO2002028107A3; EP1415474B1; US7237039B2; ATE472897T1; ATE330425T1; EP1696672B1; DE60120793D1; DE60142497D1; ES2266273T3; EP1415474A2; EP1696672A3; WO2002028107A2

Description

GEBIET DER ERFINDUNG
Die Erfindung bezieht sich auf eine robuste Kopfabschnittkomprimierung. Schemata einer robusten Kopfabschnittkomprimierung des Stands der Technik komprimieren die RTP/UDP/IP-Kopfabschnitte typischerweise auf ein Byte für Audiodatenströme und auf zwei Bytes für Videodatenströme. Dieses neue Schema komprimiert die RTP/UDP/IP-Kopfabschnitte einiger Videodatenströme auf ein Byte.
HINTERGRUND DER ERFINDUNG
Das aktuelle Problem bei einer Komprimierung des Kopfabschnitts besteht darin, dass bei einigen Medien, wie Video, sowohl die komprimierte Sequenznummer (SN) als auch der komprimierte Zeitstempel (TS) in den meisten, wenn nicht allen komprimierten Paketen gesendet werden müssen. Die Erfindung erlaubt es einem, nur die SN zu senden und den TS aus der SN abzuleiten. Die Erfindung wird durch die angefügten Ansprüche definiert.
ZUSAMMENFASSUNG DER ERFINDUNG
Das neue Schema zieht Vorteil aus dem Muster, das im Mediendatenstrom beobachtet wird, um es dem Komprimierer zu erlauben, öfter in den höchsten Komprimierzustand (SO oder Zustand zweiter Ordnung, second order state) zu gelangen.
Andere Vorteile werden leicht erkennbar, wenn die Erfindung durch Bezug auf die folgende detaillierte Beschreibung und die begleitenden Zeichnungen besser verständlich wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt typische Fälle eines TS als eine Funktion der SN für Audiodaten;
2 zeigt typische Falle eines TS als eine Funktion der SN für Videodaten;
3A zeigt SO-Mustern, TS als eine Funktion der SN;
3B zeigt IP-ID als eine Funktion der SN;
3C zeigt ein M-Bit als eine Funktion der SN; und
4 ist ein logisches Diagramm, das die logischen Zustände des Komprimierers zeigt.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
GRUNDSTRUKTUR DER KOMPRIMIERUNG DES KOPFABSCHNITTS
Für einen Überblick über die Grundstruktur der robusten Komprimierung wird Bezug genommen auf Robuste Kopfabschnittskomprimierung (Robust header compression, ROHC), draft-ietf-rohc-rtp-02, Internet-Entwurf eines Request For Comments (RFC), der als ein Anhang hier angefügt ist. Dies wird hier nachfolgend als aktuelles Schema oder ROHC bezeichnet. Die Komprimierung kann sich in drei unterschiedlichen Zuständen befinden: Initialisierung, erste Ordnung, zweite Ordnung. Im Initialisierungszustand sendet der Komprimierer volle Kopfabschnittpakete (keine Komprimierung). Im Zustand erster Ordnung sendet er FO-Pakete, die nur kodierte, sich dynamisch ändernde Felder enthalten. Eine typische FO-Kopfabschnittgröße beträgt zwei Bytes oder mehr. Im SO-Zustand sendet er nur eine kodierte SN. Der SO-Zustand ist definiert relativ zu einem Muster, das auf eine Serie von Kopfabschnittfeldern folgt. Es gibt verschiedene Modi, in welchen das Komprimierungsschema arbeiten kann. Im zuverlässigen Modus gewährleistet der Komprimierer durch Bestätigungen vom Dekomprimierer, dass der Dekomprimierer synchronisiert ist, bevor man in einen höheren Komprimierungszustand geht. Im einseitig gerichteten oder optimistischen Modus, geht der Komprimierer, wenn er schätzt, dass aller Wahrscheinlichkeit nach der Dekomprimierer synchronisiert ist, in einen höheren Komprimierungszustand. Der optimistische und einseitig gerichtete Modus erfordert es, dass der Dekomprimierer beispielsweise durch die Verwendung einer Prüfsumme prüfen kann, ob der Komprimierer und der Dekomprimierer tatsächlich synchronisiert sind.
SO-Muster:
Das aktuelle Muster ist definiert als:

– Differenz zweiter Ordnung (relativ zur SN) vom TS ist null
– Differenz zweiter Ordnung von IP-ID ist null
– alle verbleibenden Felder sind konstant.

Dies hat sich für Audiodaten als sehr gut erwiesen. Für einen typischen Audiodatenstrom sollte das Muster für die Pakete verifiziert werden, die während einem Sprachstoß erzeugt werden (das heißt, wenn tatsächlich Sprache detektiert und durch den Kodierer kodiert wird). Da gewöhnlicherweise keine oder nur wenige (Behaglichkeitsrauschen) Pakete während Stille erzeugt werden, führt dies dazu, dass die ersten wenigen Pakete eine Sprachstoß als FO-Pakete zu senden sind, und der Rest der Pakete als SO gesendet wird. Dieses Muster ist jedoch für Videodaten nicht geeignet. Dies kann man in den 1 und 2 sehen, die typische Fälle des TS als eine Funktion der SN jeweils für Audio- und Videodaten zeigen. In 1 ist es klar, dass die Differenz zweiter Ordnung über lange Zeitperioden null ist. In 2 jedoch springen die Zeitstempel häufiger (an jeder Framegrenze) und die Differenz zweiter Ordnung ist nur über kurze Zeitperioden null (bei den Paketen, die zu einem gegebenen Frame gehören, die alle dieselben Zeitstempel haben).
Als eine Konsequenz kann es im Fall von Videodaten passieren, dass der Komprimierungszustand im FO stecken bleibt. Im zuverlässigen Modus kann, wenn die Umlaufzeit (RTT) mehr als ein Framesprung beträgt (das ist die Zeit zwischen zwei kodierten Frames), der Komprimierer nicht zuverlässig in den SO-Zustand (Zustand zweiter Ordnung) gelangen. Sogar im Fall einer sehr schnellen RTT oder im optimistischen Modus würde der Komprimierungszustand an jeder Framegrenze zurück zum FO gehen.
Wie man aus 2 sehen kann, ist der TS eine Treppenfunktion der SN. Diese Treppenfunktion könnte ein Muster sein, das für den SO verwendet wird. Um diese Funktion als ein Muster zu qualifizieren, muss sie vollständig bekannt sein. Mit anderen Worten, die Länge einer Stufe und der Sprung zwischen Stufen sollte über eine ausreichend lange Zeitdauer, das heißt mehrere Male die RTT, konstant sein. Wir argumentieren hier, dass dies der Fall sein kann, zumindest dann, wenn B-Frames nicht verwendet werden. B-Frames werden in diesem Dokument später berücksichtigt. Im Effekt sind Nutzdatenformate für eine Videokodierung so, dass ein gegebenes RTP-Paket nicht Videodaten von zwei unterschiedlichen Frames enthalten soll. Zwei aufeinanderfolgende RTP-Pakete (wie sie von der Senderanwendung erzeugt werden) werden entweder denselben RTP-Zeitstempel haben, wenn sie Daten vom selben Frame befördern, oder ihre Zeitstempeldifferenz wird das Zeitintervall zwischen ihren jeweiligen Frameabtastaugenblicken widerspiegeln. Um vorhersagbar zu sein, sollten daher die Anzahl der Pakete pro Frame und der Framesprung konstant sein. Wir zeigen hier später, dass in vielen Fällen ein Videokodierer diese Parameter konstant halten kann.
Für die Robustheit können Videoanwendungen wählen, ein Videobild so zu paketieren, dass es eine konstante Anzahl von Makroblöcken enthält, oder dass mit anderen Worten jedes Videobild identisch aufgeteilt wird. Dies ist so, wie wenn ein Audiopaket eine gegebene Länge der Audiodaten abdeckt. Der einzige gute Grund (den wir zumindest kennen) dafür, dass die sendende Anwendung dies anders machen will, besteht darin, dass sie die maximale Paketgröße begrenzen will. Dies würde implizieren, dass einige Bilder mehr Pakete als die gewöhnliche Anzahl von Paketen pro Frame aufweisen. Die Anzahl solcher Frames wird jedoch oft begrenzt. Beispielsweise könnte ein Intraframe mit einer höheren Anzahl von Paketen gesendet werden. Dies würde implizieren, dass die Komprimierung in den FO geht, wenn diese Pakete komprimiert werden.
Einem Kodierer wird eine Zielframerate gegeben. So lange der Kodierer seine Zielframerate erfüllt, wird der Zeitstempelsprung konstant sein. Kodiererimplementierungen erfüllen jedoch gewöhnlicherweise nur eine mittlere Zielframerate und der Framesprung kann variabel sein. Nichtsdestotrotz kann zumindest im Fall des Streaming ein Kodierer einen höheren Pufferspeicher (eine höhere Verzögerung) verwenden, der eine größere Flexibilität bei der Ratensteuerung liefert und die Zielframerate während der Verbindung (oder zumindest über eine lange Zeitdauer) aufrecht hält. Es wird erwartet, dass die Erfindung für die so gestalteten Kodierer nützlich ist. Zusätzlich sollte das RTP-Markierungsbit nur für das letzte Paket eines Frames gesetzt werden. Dies kann dann auch vom Muster abgeleitet werden.
Wir definieren somit ein Muster als:

– TS ist eine Funktion f der SN, wobei f allgemeiner als nur eine lineare Extrapolation ist. Beispielsweise kann f eine Treppenfunktion von der SN sein, die Stufen konstanter Länge und konstante Sprünge zwischen den Stufen aufweist.
– Das Markierungsbit stellt auch eine Funktion g der SN dar. Beispielsweise wird das Markierungsbit nur für das letzte Paket jeder Stufe gesetzt.
– Die Differenz IP-ID zweiter Ordnung ist null (dieselbe wie bei Audiodaten).

Unter Verwendung von Videodaten als Beispiel ist dieses Muster in den 3a, 3b, 3c für eine Serie von 40 Paketen gezeigt, wobei die Framerate 10 fps (frames per second, Bilder pro Sekunde) ist und die Anzahl der Pakete pro Frame 9 ist.
Komprimierer- und Dekomprimiererlogik
Die einzige Modifikation am aktuellen Schema, die durch das neue Muster eingeführt wird, bezieht sich auf die Übergänge des Komprimierers und des Dekomprimierers zwischen dem FO- und dem SO-Zustand. Der Komprimierer ist derjenige, der die Entscheidung fällt, in welchem Zustand gearbeitet wird. Der Dekomprimierer folgt den Entscheidungen des Komprimierers. Er arbeitet im FO-Zustand, wenn er FO-Pakete empfängt, und er arbeitet im SO-Zustand, wenn er SO-Pakete empfängt. Die Komprimiererlogik ist in 4 gezeigt. Der FO-Zustand ist hier konzeptionell in zwei Unterzustände FO_1 und FO_2 aufgeteilt. Der Komprimierer betritt den FO in FO_1 und bewegt sich zum FO_2, wenn ein Muster detektiert wird. Der Komprimierer geht vom FO_2 in den SO, wenn der Dekomprimierer synchronisiert ist, das heißt, wenn der Dekomprimierer fähig sein würde, SO-Pakete zu dekomprimieren.
Die für das neue Schema speziellen Punkte sind somit:

– Wie der Dekomprimierer Pakete im SO-Zustand dekomprimiert
– Wie der Komprimierer das Muster erwirbt
– Wie der Komprimierer weiß, dass der Dekomprimierer synchronisiert ist, um in den SO-Zustand zu gehen

Wir untersuchen nachfolgend jeden dieser Punkte.
Dekomprimierung von SO-Paketen
Im SO-Zustand muss der Dekomprimierer die Musterfunktionen f und g kennen, um die SO-Pakete zu dekomprimieren. Wenn man wieder das Videobeispiel verwendet, muss der Dekomprimierer n, die Anzahl der Pakete pro Bild, und TS_inc, das Zeitstempelinkrement, zwischen zwei Frames, kennen. Zusätzlich muss er vorher erfolgreich ein Paket dekomprimiert haben, das ein erstes Paketbild war.
SN_0 sei die Sequenznummer und TS_0 der Zeitstempel eines solchen Pakets. Für jedes ankommende SO-Paket dekomprimiert der Dekomprimierer die SN wie im aktuellen Schema. Wenn n und m der Quotient und Modulo von SN-SN_0 mit q sind, das heißt SN-SN_0 = q·n + m, berechnet der Dekomprimierer den Paket-TS gemäß TS = TS_0 + q·TS_inc. Das Markierungsbit M wird nur gesetzt, wenn m = n – 1. Alle anderen Felder werden wie im aktuellen Schema erhalten.
Mustererkennung
Der Komprimierer kann die Funktion durch Beobachtung des Datenstroms/lernen oder API oder andere Mittel bestimmen. Wenn man wieder das Videobeispiel verwendet und eine Datenstrombeobachtung annimmt, so erfordert das neue Muster, dass es genug Pakete vom Sender erhält, bevor eine Entscheidung gefällt werden kann. Dies erfordert wiederum, eine Kopie einer gewissen Anzahl vergangener Pakete zwischenzuspeichern.
Das Muster könne erkannt werden, wenn in diesem Zwischenspeicher nach drei Paketen gesucht wird, deren (SN, TS, M, IP-ID) so sind, dass die IP-ID-Differenzen zweiter Ordnung null sind und (SN_1, TS_1, M_1)(SN_2, TS_2, M_2)(SN_3, TS_3, M_3) so sind, dass:
SN_2 = SN_1 + 1
TS_3 = TS_2
M_1 = 1
M_2 = 0
M_3 = 1
Dies impliziert, dass SN_2 ein erstes Paketbild ist und dass TS_inc = TS_2 – TS_1, und dass die Anzahl der Pakete pro Bild n = SN_3 – SN_2 ist.
Es gibt einen speziellen Fall, bei dem das Muster durch zwei Pakete (SN_1, TS_1, M_1)(SN_2, TS_2, M_2) erkannt werden kann, so dass:
SN_2 = SN_1 + 1
M_1 = 1
M_2 = 1
In diesem Fall gibt es nur ein Paket pro Frame.
Synchronisation des Dekomprimierers
Im aktuellen Schema muss der Komprimierer nur zwei Bestätigungen vom Dekomprimierer erhalten, um zu gewährleisten, das letzterer synchronisiert ist. Der Dekomprimierer leitet von den zwei zuletzt empfangenen Paketen die Differenzen erster Ordnung ab, die erforderliche sind, um die SO-Pakete zu dekomprimieren.
Mit dem neuen Muster ist dies jedoch nicht ausreichend. Es gibt mehrere Wege, mit denen der Komprimierer gewährleisten kann, dass der Dekomprimierer synchronisiert ist. Wir schlagen drei von ihnen vor.

– Nach dem Erkennen des Musters kann der Komprimierer explizit die Musterfunktionen f und g an den Dekomprimierer unter Verwendung einer In-Band-Signalisierung senden. Wenn man wieder das Videobeispiel verwendet, so sendet der Komprimierer n und TS_inc zusammen mit einer Anzeige, dass das Markierungsbit nur für das letzte Paket jeder Stufe gesetzt ist. Der Komprimierer muss dann nur gewährleisten, dass der Dekomprimierer ein Paket mit einem gesetzten Markierungsbit (erstes Bildpaket) empfangen hat. Er weiß dann, dass der Dekomprimierer alle Information hat, die benötigt wird, um das Paket zu dekomprimieren. Nach dem Empfangen eines FO-Kopfabschnitts, der die Musterbeschreibung trägt, sollte der Empfänger versuchen, Pakete mit dem gesetzten Markierungsbit zu bestätigen, so dass der Komprimierer so bald wie möglich beginnen kann, SO-Pakete zu senden. Positiv daran: Die Logik des Dekomprimierers kann einfach gehalten werden (es besteht keine Notwendigkeit einer Mustererkennung). Der Komprimierer muss nicht im Vorhinein wissen, ob der Dekomprimierer die In-Band-Signalisierung nicht interpretieren kann; dies kann durch eine ZURÜCKWEISUNG vom Dekomprimierer signalisiert werden, was ein "Nicht erkannt" bewirkt. Negativ daran: Zusätzlicher Overhead, Änderungen am aktuellen Paketformat.
– Alternativ kann der Komprimierer die Bestätigungen beobachten, die vom Dekomprimierer empfangen werden, um zu bestimmen, ob der Dekomprimierer die Musterfunktionen f und g erworben hat. Der Dekomprimierer führt auch eine Mustererkennung auf den dekomprimierten Paketen im FO-Modus aus. Wenn das Muster erworben wurde, wird dies in den nachfolgenden Bestätigungen, die an den Komprimierer gesandt werden, signalisiert. Wenn der Komprimierer genug Bestätigungen erhält, um anzuzeigen, dass das Muster detektiert wurde, kann er mit dem Senden der SO-Pakete beginnen. Positiv daran: Der Overhead wird bei einem Minimum gehalten. Das Inbandsignalisierungsformat muss nicht genormt werden. Negativ daran: Der Dekomprimierer muss eine Mustererkennung durchführen, was mehr Komplexität und größere Verzögerungen in den Fällen verursacht, bei denen die Verbindung Pakete verliert, die für die Erkennung verwendet werden; die Musterfunktionen müssen genormt werden. Der Komprimierer muss auch wissen, ob der Dekomprimierer die Funktion f detektieren kann (der Empfang von Bestätigungen allein gewährleistet nicht, dass der Dekomprimierer die Funktion erworben hat); dies könnte durch einen Fähigkeitsaustausch oder eine Verhandlung ausgeführt werden.
– Der Dekomprimierer führt eine Mustererkennung durch, und der Komprimierer führt auch eine Mustererkennung für die Pakete durch, die vom Dekomprimierer bestätigt wurden. Mit anderen Worten, der Komprimierer versucht herauszufinden, ob das Muster erkannt werden kann, indem er nur die Pakete verwendet, von denen er sicher ist, dass sie der Dekomprimierer empfangen hat. Der Dekomprimierer sollte dann wählen, Pakete zu bestätigen, von denen bekannt ist, dass sie ausreichen, das Muster zu erkennen, beispielsweise das oben gezeigte Triplett. Positiv daran: keine Modifikation beim Paketformat notwendig. Dieselben Paketformate können für die Audiomuster und die Videomuster verwendet werden. Negativ daran: zusätzliche Komplexität, Verzögerung vor Eintritt in den SO, reduziert die Freiheit des Dekodierers, zu wählen, ob er ein Paket bestätigt oder dies nicht tut.

B und PB-Frames
Wir präsentierten das Muster als ein typisches Muster für Video. Wenn jedoch B-Frames verwendet werden, wird diesem Muster nicht gefolgt. Wir betrachten B-Frames nicht als typischen Fall aus den folgenden Gründen:

– B-Frames werden nur von einer begrenzten Anzahl von Kodierern-Dekodierern verwendet. Sie werden nicht im einfachen MPEG 4 Profil verwendet.
– Bei einer Videokonferenz mit niedriger Bitrate werden B-Frames als nicht geeignet angesehen. Das ergibt sich, da das P-Frame empfangen werden muss, bevor das B-Frame dekodiert werden kann. Bei einer typischen Framerate von 10 fps würde dies eine zusätzliche Ende-zu-Ende-Verzögerung von 100 ms bedeuten.

In einem Fall, bei dem B-Frames verwendet werden, könnte es dennoch ein typisches Muster geben, wenn der Kodierer sich entscheidet, eine feste Anzahl von B-Frames pro Anzahl des kodierten Bildes zu kodieren, wobei beispielsweise jedes andere Frame ein B-Frame ist.
Schlussfolgerung
Diese Schema könnte für viele Anwendungen vorteilhaft sein. Es gibt keine Strafe, wenn eine Anwendung dem Muster nicht folgt. Zusätzlich könnte ein solches Schema, wenn es standardisiert wurde, ein Anreiz für Anwendungen sein, eine Paketierstrategie zu wählen, die einer Kopfabschnittkomprimierung gewogen ist, das heißt, die einem SO-Muster folgt. Insbesondere können Gestalter einer zukünftigen Videoanwendung für 3G Mobilendgeräte dies berücksichtigen. Anhang: Entwurf RFC Robuste Kopfabschnittkomprimierung Draft-ietf-rohc-rtp-02.txt

Netzwerk Arbeitsgruppe Carsten Bormann (Herausgeber) TZI Uni Bremen
INTERNET-ENTWURF

Ablauf: März 2000
Carsten Burmeister, Matsushita
Christopher Clanton, Nokia
Mikael Degermark, U von Arizona
Hideaki Fukushima, Matsushita
Hans Hannu, Ericsson
Lars-Erik-Jonsson, Ericsson
Rolf Hakenberg, Matsushita
Tnima Koren, Cisco
Khiem Le, Nokia
Zhigang Liu, Nokia
Akihiro Miyazaki, Matsushita
Krister Svanbro, Ericsson
Thomas Wiebke, Matsushita
Haihong Zhen, Nokia
September 18, 2000

Robuste Kopfabschnittskomprimierung <draft-ietf-rohc-rtp-02.txt>
Status dieser Notiz
Dieses Dokument ist ein Internet-Entwurf und befindet sich in voller Übereinstimmung mit allen Bestimmungen des Abschnitts 10 der RFC2026.
Internet-Entwürfe sind Arbeitsdokumente der Internet Engineering Task Force (IETF), ihrer Bereiche und ihrer Arbeitsgruppen. Man beachte, dass andere Gruppen auch Arbeitsdokumente als Internet-Entwürfe verarbeiten können.
Internet-Entwürfe sind Entwurfsdokumente, die maximalen sechs Monate gültig sind und die jederzeit aktualisiert, ersetzt oder überholt werden können durch andere Dokumente. Es ist unangebracht, Internet-Entwürfe als Referenzmaterial zu verwenden oder sie anders als "laufende Arbeiten" zu zitieren.
Auf die Liste der aktuellen Internet-Entwürfe kann zugegriffen werden bei http://www.ietf.org/ietf/lid-abstracts.txt
Auf die Liste der Internet-Entwurf Schattenverzeichnisse kann zugegriffen werden bei http://www.ietf.org/shadow.html Dieses Dokument ist ein Produkt der IETF ROHC WG. Kommentare sollten an seine Mailingliste rohc@cdt.luth.se gerichtet werden.
Bormann (Herausgeber) [Seite 1]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Zusammenfassung
Existierende Komprimierungsschemata für Kopfabschnitte arbeiten nicht gut, wenn sie über Verbindungen mit signifikanten Fehlerraten verwendet werden, insbesondere dann, wenn die Umlaufzeit der Verbindung lang ist. Für viele in der Bandbreite begrenzte Verbindung, bei denen die Kopfabschnittkomprimierung wesentlich ist, sind solche Eigenschaften gebräuchlich.
Eine Grundstruktur einer Kopfabschnittkomprimierung und ein sehr robustes und effizientes Schema einer Kopfabschnittkomprimierung wird in diesem Dokument eingeführt, das an die Eigenschaften der Verbindung angepasst werden kann, über der es verwendet wird, und auch an die Eigenschaften der Paketdatenströme, die es komprimiert.
Verlauf der Überarbeitungen

– 02: Hauptänderungen nach 48. IETF
– 01: kleine redaktionelle Änderungen für die 48. IETF

– 00: Dokument geschaffen aus ROHC Eingaben Bormann (Herausgeber) [Seite 2] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000 Inhaltsverzeichnis

Status dieser Notiz	1
Zusammenfassung	2
Verlauf der Überarbeitungen	2
Inhaltsverzeichnis	2

0. ROHC WG interner kurzfristiger Zeitplan	7
1. Einführung	8
2. Terminologie	10
3. Hintergrund	14
3.1 Grundsätze der Kopfabschnittkomprimierung	14
3.2 Existierende Schemata zur Kopfabschnittkomprimierung	14
3.3 Anforderungen an ein neues Schema zur Kopf abschnittkomprimierung	16
3.4 Klassifikation der Kopfabschnittfelder	16
4. Grundlagen der Kopfabschnittkomprimierung	18
4.1 Annahmen für den Betrieb	18
4.2 Dynamik	19
4.3 Komprimierungs- und Dekomprimierungszustände	20
4.3.1 Zustände des Komprimierers	20
4.3.1.1 Initiierungs- und Wiederholungszustand (IR)	21
4.3.1.2 Zustand erster Ordnung (FO)	21
4.3.1.3 Zustand zweiter Ordnung (SO)	21
4.3.2 Zustände des Dekomprimierers	22
4.4 Betriebsarten	22
4.4.1 Unidirektionaler Modus – U-Modus	23
4.4.2 Bidirektionaler optimistischer Modus – O-Modus	24
4.4.3 Bidirektionaler zuverlässiger Modus – R-Modus	24
4.5 Kodierverfahren	24
4.5.1 Kodierung der niederwertigsten Bits (LSB)	24
4.5.2 LSB-Kodierung auf Fensterbasis (W-LSB-Kodier.)	26
4.5.3 Skalierte RTP Zeitstempelkodierung	27
4.5.4 Auf Zeitgeber basierende Komprimierung des RTP-Zeitstempels	29
4.5.5 Versatz IP-ID Kodierung	31
4.5.6 Unabhängige Variablenlängenwerte	32
4.5.7 Kodierte Werte über mehrere Felder in komprimierten Kopfabschnitten	32
5. Das Protokoll	34
5.1 Datenstrukturen	34
5.1.1 Pro-Kanal-Parameter	34
5.1.2 Pro-CID Parameter, Profile	34
5.1.3 Kontexte	34

5.2 Pakettypen	34
5.2.1 Paketformate vom Komprimierer zum Dekomprimierer	35
5.2.2 Rückkopplungspakete vom Dekomprimierer zum Komprimierer	36
5.2.3 Für einen Modusübergang benötigte Parameter	36
5.3 Betrieb im unidirektionalen Modus 5.3.1 Komprimierer Zustände und Logik (U-Modus)	37
5.3.1.1 Zustandsübergangslogik (U-Modus)	37
5.3.1.1.1 Optimistische Annäherung Aufwärtsübergang	37
5.3.1.1.2 Zeitabläufe, Abwärtsübergang	38
5.3.1.1.3 Notwendigkeit für Aktualisierungen, Abwärtsübergang	38
5.3.1.2 Komprimierungslogik und verwendete Pakete (U-Modus)	38

Bormann (Herausgeber) [Seite 3] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

5.3.1.3 Rückkopplung im unidirektionalen Modus	38
5.3.2 Dekomprimierer, Zustände und Logik (U-Modus)	39
5.3.2.1 Zustandsübergangslogik (U-Modus)	39
5.3.2.2 Dekomprimierlogik (U-Modus)	39
5.3.2.2.1 Entscheidung ob Dekomprimierung erlaubt	39
5.3.2.2.2 Rekonstruiere und verifiziere den Kopfabschnitt	40
5.3.2.2.3 Gründe für CRC-Fehlanpassungen	40
5.3.2.2.4 Erkennung von Kontextbeschädigungen	41
5.3.2.2.5 Reparatur des Zyklischwerdens der SN	41
5.3.2.2.6 Reparatur unkorrekter SN-Aktualisierungen	42
5.3.2.3 Rückkopplung im unidirektionalen Modus	43
5.4 Betrieb im bidirektionalen optimistischen Modus	44
5.4.1 Komprimierer Zustände und Logik (O-Modus)	44
5.4.1.1 Zustandsübergangslogik	44
5.4.1.1.1 Kontextanforderungen, negative Bestätigungen (NACKs)	44
5.4.1.1.2 Optionale Bestätigungen	44

5.4.1.2 Komprimierungslogik und verwendete Pakete	44
5.4.2 Dekomprimierer Zustände und Logik	45
5.4.2.1 Dekomprimierlogik	45
5.4.2.1.1 Auf einem Zeitgeber basierende Zeitstempeldekomprimierung	45
5.4.2.2 Rückkoppelungslogik	45
5.5 Betrieb im bidirektionalen zuverlässigen Modus	46
5.5.1 Komprimierer Zustände und Logik	46
5.5.2 Dekomprimierer Zustände und Logik	46
5.5.2.1 Dekomprimierlogik	46
5.5.2.2 Rückkopplungslogik	46
5.6 Modusübergänge	48
5.6.1 Komprimierung und Dekomprimierung während Modusübergängen	48
5.6.2 Übergang vom unidirektionalen in den optimistischen Modus	49
5.6.3 vom optimistischen in den zuverlässigen Modus	50
5.6.4 vom unidirektionalen in den zuverlässigen Mod	50
5.6.5 vom zuverlässigen in den optimistischen Modus	50
5.6.6 Übergang zum unidirektionalen Modus	51
5.7 Paketformate	53
5.7.1 Pakettyp 0: UO-0, R-0, R-0-CRC	53
5.7.2 Pakettyp 1: (R-Modus): R-1, R-1-TS, R-1-ID	53
5.7.3 Pakettyp 1: (UO-Modi): UO-1, UO-1-ID, UO-1-TS	55
5.7.4 Pakettyp 2: UOR-2	56
5.7.5 Erweiterungsformate	57
5.7.6 Rückkopplungspakete: RÜCKKOPPELUNG-3 und RÜCKKOPPELUNG-4	60
5.7.7 IR und IR_DYN Pakete	62
5.7.7.1 Grundstruktur des IR-Pakets	62
5.7.7.2 Grundstruktur des IR-DYN-Pakets	63
5.7.7.3 Initialisierung IPv6 Kopfabschnitt [IPv6]	64
5.7.7.4 Initialisierung des IPv4 Kopfabschnitts [IPv4, Abschnitt 3.1]	65
5.7.7.5 Initialisierung des UDP-Kopfabschnitts [RFC-768]	65
5.7.7.6 Initialisierung des RTP-Kopfabschnitts [RTP]	66

5.7.7.7 Kopfabschnitt der minimalen Einkapselung [RFC 2004, Abschnitt 3.1]	67
5.8 Listenbasierte Komprimierung	68
5.8.1 CSRC-Komprimierung	68
5.8.1.1 Transformationsklassifikation für CSRC-Liste	68

Bormann (Herausgeber) [Seite 4] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

5.8.1.2 Kodierschemata	68
5.8.1.3 Format der komprimierten CSRC-Liste	69
5.8.1.3.1 Schema des ausschließlichen Einschubs	69
5.8.1.3.1.1 R-Modus	69
5.8.1.3.1.2 UO-Modi	70
5.8.1.3.2 Schema der ausschließlichen Entfernung	71
5.8.1.3.2.1 R-Modus	71
5.8.1.3.2.1 UO-Modus	71
5.8.1.3.3 Allgemeines Schema	72
5.8.1.3.3.1 R-Modus	72
5.8.1.3.3.2 UO-Modus	73
5.8.2 Kopfabschnittskomprimierung für Kopfabschnitte mit IPv6 Erweiterung	73
5.8.2.1 Terminologie	74
5.8.2.2 Transformationsklassifikation und Kodierschemata	74
5.8.2.2.1 Transformationsklassifikation	74
5.8.2.2.2 Kodierschemata	75
5.8.2.2.3 Spezielle Handhabung	75
5.8.2.2.3.1 Spezielle Handhabung von AH	75
5.8.2.2.3.2 Einkapselungssicherheit des Nutzdatenkopfabschnitts	76
5.8.2.2.3.3 Spezielle Handhabung des nächsten Kopfabschnittfeldes	76
5.8.2.3 Paketformat	78
5.8.2.3.1 Format in der Erweiterung des „11" Kopfabschnitts	78
5.8.2.3.2 Format des komprimierten Kopfabschnitts mit IPv6 Erweiterung	79

5.8.2.3.2.1 Schema des ausschließlichen Einschubs	79
5.8.2.3. 2.1.1 R-Modus	79
5.8.2.3.2.2 Schema des ausschließlichen Entfernens	80
5.8.2.3.2.2.1 R-Modus	80
5.8.2.3.2.3 Schema der ausschließlichen Änderung des Inhalts	81
5.8.2.3.2.3.1 R-Modus	81
5.8.2.3.2.2.2 UO-Modus	80
5.8.2.3.2.4 Nicht komprimiertes Schema (dem R-Modus und den UO-Modi gemeinsam)	82
5.9 Kopfabschnittkomprimierungs-CRCs, Abdeckung und Polynome	83
5.9.1 IR & IR-DYN Paket CRCs	83
5.9.2 CRCs in komprimierten Paketen	83
6. Implementierungsangelegenheiten	84
6.1 Umgekehrte Dekomprimierung	84
6.2 RTCP	85
7. Weitere Arbeit	86
7.3 Tunneln	86
7.3.1 Kopfabschnittskomprimierung für IPv4 Tunnelkopfabschnitt	86
7.3.1.1 Feldtyp des tunnelnden Kopfabschnitts beim mobilen IPv4	86
7.3.1.2 Komprimierung des tunnelnden Kopfabschnitts im MIPv4	87
7.3.1.2.1 IP in IP Einkapselung im IPv4	87
7.3.1.2.2 Minimum-Einkapselung im IPv4	87
7.3.1.2.3 Allgemeine Verkehrslenkungs-Einkapselung im IPv4	87
7.4 Nicht-RTP UDP Verkehr	88
8. Abschnitt 8 wurde entfernt	90
9. Sicherheitsbetrachtungen	90
10. Danksagungen	90
11. Betrachtungen hinsichtlich des geistigen Eigentums	91
12. Referenzen	92

Bormann (Herausgeber) [Seite 5] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

13. Adressen der Autoren	93
Anhang A. Detaillierte Klassifikation der Kopfabschnittsfelder	94
A.1 Allgemeine Klassifikation	94
A.1.1 IPv6 Kopfabschnittsfelder	95
A.1.2 IPv4 Kopfabschnittsfelder	96
A.1.3 UDP Kopfabschnittsfelder	98
A.1.4 RTP Kopfabschnittsfelder	99
A.1.5 Zusammenfassung für IP/UDP/RTP	100
A.2 Analyse der Änderungsmuster der Kopfabschnittsfelder	100
A.2.1 IPv4 Identifikation	102
A.2.2 IP Verkehrsklasse/Typ des Dienstes	103
A.2.3 IP Sprunggrenze/Lebensdauer	104
A.2.4 UDP Prüfsumme	104
A.2.5 RTP CSRC Zähler	104
A.2.6 RTP Markierung	104
A.2.7 RTP Nutzdatentyp	104
A.2.8 RTP Sequenznummer	104
A.2.9 RTP Zeitstempel	104
A.2.10 RTP Beitragende Quellen (CSRC)	105
A.3 Strategien für die Kopfabschnittskomprimierung	105
A.3.1 Überhaupt kein Senden	105
A.3.2 Übertragung nur anfänglich	106
A.3.3 Übertrage anfänglich aber bereit für Aktualisierung	106
A.3.4 Vorbereitet für Aktualisierung oder häufiges Senden so wie es ist	106
A.3.5 Garantie kontinuierlicher Robustheit	106
A.3.6 Übertragen wie es ist in allen Paketen	107
A.3.7 Errichten von Delta und bereit zur Aktualisierung	107
Anhang E – Kodierbeispiele	108
E.1 Grund VLE	108
E.2 Auf einem Zeitgeber basierende VLE	109

(Anmerkung des Herausgebers: Das Inhaltsverzeichnis ist nicht notwendigerweise aktualisiert worden. Ich habe Text, den ich für fragwürdig halte, kursiv markiert, und Text, von dem ich denke, dass er einfach gestrichen werden sollte, markiert, indem ich ihn durchgestrichen habe). Bormann (Herausgeber) [Seite 6] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

0.ROHC WG interner Kurzzeitplan
Dieses Dokument erfasst den Zustand der ROHC RTP Spezifikation am 18. September 2000. Zur Information gestaltet sich der interne Kurzzeitplan der ROHC WG folgendermaßen:

18 September ROHC-02 vollendet (dieses Dokument)

Entwurfsüberarbeitung und Diskussion Komplementäre Beiträge geschaffen

29 September Abschluss der Entwurfsüberarbeitung und Diskussion

2. Oktober ROHC-03 vollendet

4. Oktober Beurteilung, ob Entwurf bereit für letzten Aufruf
Wenn er an diesem Punkt nicht als bereit für den letzten Aufruf der WG an diesem Punkt ist:

4. Oktober Identifizierung was fehlt/nicht korrekt ist

Weitere Diskussion und Beiträge

13. Oktober Abschluss der „zweiten" Entwurfsüberarbeitung und Diskussion

16. Oktober ROHC-04 vollendet
Letzter Aufruf der WG bei Vollendung von ROHC-03 beziehungsweise ROHC-04 (in Abhängigkeit vom Fortschreiten, wie das oben gezeigt wurde)
Bormann (Herausgeber) [Seite 7]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
1. Einleitung
Während der letzten fünf Jahre wurden insbesondere zwei Kommunikationstechnologien durch die allgemeine Öffentlichkeit verwendet: zellulare Telephonie und das Internet. Zellulare Telephonie hat die Benutzer mit der revolutionären Möglichkeit versehen, dass sie mit einer vernünftigen Dienstqualität immer erreichbar sind, wo immer sie sich auch befinden. Der Hauptdienst, der von den zugehörigen Endgeräten geliefert wurde, war die Sprache. Das Internet auf der anderen Seite wurde von Anfang an für mehrere Dienste gestaltet, und seine Flexibilität für alle Arten der Nutzung ist eines seiner Stärken gewesen. Internetendgeräte sind im allgemeinen Mehrzweckgeräte gewesen und sie wurden über feste Verbindungen angehängt. Die wahrgenommene Qualität mancher Dienste (wie der Internettelephonie) ist manchmal gering gewesen.
Heutzutage gewinnt die IP-Telephonie dank verbesserter technischer Lösungen an Schwung. Es scheint vernünftig anzunehmen, dass in den zukünftigen Jahren IP ein allgemein verwendeter Weg werden wird, um Telephonie auszuführen. Einige zukünftige zellulare Telefonverbindungen können auch auf IP und der IP-Telephonie basieren. Zellulare Telefone können universeller werden und sie können IP-Stacks haben, die nicht nur Audio und Video sondern auch ein Webbrowsen, E-Mail, Spiele etc. unterstützen.
Eines der Szenarien, die wir vorhersagen, könnte dann das in Figur 1.1 sein, bei dem zwei mobile Endgeräte miteinander kommunizieren. Beide sind mit Basisstationen über zellulare Verbindungen verbunden, und die Basisstationen sind miteinander durch ein leitungsgebundenes (oder möglicherweise drahtloses) Netzwerk verbunden. Statt der zwei mobilen Endgeräte könnte natürlich ein mobiles Endgerät und ein verdrahtetes Endgerät stehen, aber im Fall mit den zwei zellularen Verbindungen ist die Technologie anspruchsvoller.
Figur 1.1: Szenario für IP-Telephonie über zellulare Verbindungen Bormann (Herausgeber) [Seite 8]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Es ist offensichtlich, dass das verdrahtete Netzwerk auf dem IP basieren kann. Bei den zellularen Verbindungen ist die Situation weniger klar. Das IP könnte im festen Netzwerk beendet werden, und spezielle Lösungen könnten für jeden unterstützten Dienst über die zellulare Verbindung implementiert werden. Dies würde jedoch die Flexibilität der unterstützten Dienste begrenzen. Wenn es technisch und ökonomisch möglich ist, würde eine Lösung mit dem reinen IP auf dem ganzen Weg von Endgerät zu Endgerät gewisse Vorteile haben. Um das als brauchbare Alternative zu haben, müssen eine Anzahl von Problemen angesprochen werden, insbesondere Probleme im Hinblick auf die Bandbreiteneffizienz.
Bei zellularen Telefonsystemen ist es von entscheidender Bedeutung, die raren Funkressourcen auf eine effiziente Weise zu verwenden. Eine ausreichende Anzahl von Benutzern pro Zelle ist entscheidend, da ansonsten die Einsatzkosten [CELL] unerschwinglich sind. Die Qualität des Sprachdienstes sollte auch so gut wie bei den heutigen zellularen Systemen sein. Es ist wahrscheinlich, dass sogar bei der Unterstützung neuer Dienste eine geringere Qualität des Sprachdienstes nur akzeptabel ist, wenn die Kosten signifikant reduziert werden.
Ein Problem bei dem IP über zellulare Verbindungen, wenn diese für interaktive Sprachübertragungen verwendet werden, ist der große Kopfabschnitt-Overhead. Sprachdaten für die IP-Telephonie werden am wahrscheinlichsten durch das RTP (RTP) übertragen. Ein Paket wird dann zusätzlich zur Verbindungsschichtfeldeinteilung (link layer framing) einen IP-(IPv4)-Kopfabschnitt (20 Oktette), einen UDP-Kopfabschnitt (8 Oktette) und einen RTP-Kopfabschnitt (12 Oktette) also insgesamt 40 Oktette aufweisen. Die Größe der Nutzdaten hängt von der Sprachkodierung und den verwendeten Rahmengrößen ab und es kann sein, dass sie nur 15–20 Oktette beträgt.
Aus diesen Zahlen ist die Notwendigkeit für das Reduzieren der Größen der Kopfabschnitte aus Gründen der Effizienz offensichtlich. Zellulare Verbindungen weisen jedoch Eigenschaften auf, die eine Kopfabschnittkomprimierung, wie sie im [IPHC, CRTP, PPPHC] definiert ist, nicht gut funktionieren lässt. Die wichtigste Eigenschaft ist das verlustbehaftete Verhalten der zellularen Verbindungen, bei denen eine Bitfehlerrate (BER), so hoch wie 1e-3 akzeptiert werden muss, um eine effiziente Verwendung der Funkressourcen zu halten [CELL]. Bei schwierigen Betriebsbedingungen kann die BER sogar 1e-2 betragen. Die andere problematische Eigenschaft ist die lange Umlaufzeit (RTT) der zellularen Verbindung, die bis zu 100–200 Millisekunden betragen kann [CELL]. Ein zusätzliches Problem besteht darin, dass die restliche BER nicht trivial ist, das heißt untere Schichten können manchmal Rahmen liefern, die nicht detektierte Fehler enthalten. Ein brauchbares Komprimierungsschema für Kopfabschnitte für zellulare Verbindungen muss auch den Verlust der Verbindung zwischen dem Komprimierungs- und dem Dekomprimierungspunkt als auch den Verlust vor dem Komprimierungspunkt handhaben.
Die Bandbreite ist die kostspieligste Ressource in zellularen Verbindungen. Die Verarbeitungsleistung ist im Vergleich dazu sehr billig. Die Implementierung oder die einfache Berechenbarkeit eines Kopfabschnittkomprimierungsschema ist deswegen weniger wichtig als sein Komprimierungsverhältnis und seine Robustheit.
Bormann (Herausgeber) [Seite 9]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
2. Terminologie
Die Schlüsselworte "Darf", "braucht nicht", "gefordert", "soll", "soll nicht", "sollte", "sollte nicht", "empfohlen", "kann" und "optional" in diesem Dokument sollen so interpretiert werden, wie das im RFC 2119 beschrieben ist.
BER
Bitfehlerrate. Zellulare Funkverbindungen haben eine ziemlich hohe BER. In diesem Dokument ist die BER gewöhnlicherweise als eine Wahrscheinlichkeit angegeben, aber man muss auch die Fehlerverteilung berücksichtigen, da Bitfehler nicht unabhängig sind.
Zellulare Verbindungen
Drahtlose Verbindungen zwischen mobilen Endgeräten und Basisstationen. Die BER und die RTT sind ziemlich hoch, um ein effizientes Gesamtsystem zu erzielen.
Komprimierungseffizienz
Die Leistung eines Kopfabschnittkomprimierungsschemas kann mit drei Parametern beschrieben werden: Komprimierungseffizienz, Robustheit und Komprimierungstransparenz. Die Komprimierungseffizienz wird dadurch bestimmt, um wie viel die Kopfabschnittsgrößen durch das Komprimierungsschema reduziert werden.
Komprimierungstransparenz
Die Leistung eines Kopfabschnittkomprimierungsschemas kann mit drei Parametern beschrieben werden: Komprimierungseffizienz, Robustheit und Komprimierungstransparenz. Die Komprimierungstransparenz ist ein Maß, wie gut das Schema gewährleistet, dass die dekomprimierten Kopfabschnitte semantisch identisch zu den ursprünglichen Kopfabschnitten sind. Wenn alle dekomprimierten Kopfabschnitte semantisch identisch zu den entsprechenden ursprünglichen Kopfabschnitten sind, beträgt die Transparenz 100 Prozent. Die Komprimierungstransparenz ist hoch, wenn die Schadensausbreitung niedrig ist.
Kontext
Der Kontext ist der Zustand, den der Komprimierer verwendet, um einen Kopfabschnitt zu komprimieren, und den der Dekomprimierer verwendet, um einen Kopfabschnitt zu dekomprimieren. Der Kontext enthält im Grunde die nicht komprimierte Version des letzten über die Verbindung gesendeten (Komprimierer) oder empfangenen (Dekomprimierer) Kopfabschnitts, mit Ausnahme der Felder im Kopfabschnitt, die "so wie sie sind" in komprimierten Kopfabschnitten eingefügt sind, oder die beispielsweise aus der Größe des Verbindungsebenenrahmens (link level frame) erschlossen werden können. Der Kontext kann auch zusätzliche Information, die den Paketstrom beschreibt, enthalten, beispielsweise die typische Zunahme bei den Sequenznummern oder Zeitstempeln zwischen den Paketen.
Bormann (Herausgeber) [Seite 10]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Kontextbeschädigung
Wenn der Kontext des Dekomprimierers nicht konsistent mit dem Kontext der Komprimierers ist, kann es sein, dass die Dekomprimierung des Kopfabschnitts nicht den ursprünglichen Kopfabschnitt wieder herstellen kann. Diese Situation kann auftreten, wenn der Kontext des Dekomprimierers nicht passend initialisiert wurde, oder wenn Pakete zwischen dem Komprimierer und dem Dekomprimierer verloren oder beschädigt wurden. Von Paketen, bei denen der Dekomprimierer erkennt, dass sie durch inkonsistente Kontexte nicht dekomprimiert werden können, wird gesagt, dass sie durch eine Kontextbeschädigung verloren gegangen sind.
Kontextreparaturmechanismus
Um eine übermäßige Kontextbeschädigung zu vermeiden, wird ein Kontextreparaturmechanismus benötigt. Kontextreparaturmechanismen können auf expliziten Anforderungen nach Kontextaktualisierungen, periodischen Aktualisierungen, die vom Komprimierer gesendet werden, oder Verfahren für die lokale Reparatur auf der Seite des Dekomprimierers basieren.
Beschädigungsausbreitung
Die Erzeugung nicht korrekt dekomprimierter Kopfabschnitte durch die Beschädigung eines oder mehrere vorheriger Pakete.
Verlustausbreitung
Misslingen der Dekomprimierung von Kopfabschnitten durch den Verlust eines oder mehrerer vorheriger Rahmen.
Fehlererkennung
Erkennung von Fehlern. Wenn die Fehlererkennung nicht perfekt ist, wird es Restfehler geben.
Fehlerausbreitung
Beschädigungsausbreitung oder Verlustausbreitung.
FLR
Frame Loss Rate (Rahmenverlustrate) wird angegeben als die Wahrscheinlichkeit, dass ein Rahmen auf dem Kanal zwischen dem Komprimierer und dem Dekomprimierer verloren gegangen ist. (Im Gegensatz dazu tragen Rahmen, die durch eine Kontextbeschädigung verloren gehen, zur Paketverlustrate bei).
Rahmen (Frame)
Ein Paket, das vom Komprimierer ausgegeben/vom Dekomprimierer empfangen wird. Man beachte, dass in diesem Dokument keine Beziehung zu anderen Rahmenkonzepten (beispielsweise der physikalischen Schicht), wie Funkrahmen, besteht.
Profil der Kopfabschnittskomprimierung
Ein Profil der Kopfabschnittskomprimierung ist eine Spezifikation, wie die Kopfabschnitte einer gewissen Art des Paketstroms über einer gewissen Art von Verbindung zu komprimieren sind. Komprimierungsprofile liefern die Details des Kopfabschnittkomprimierungsrahmenwerks, das in diesem Dokument eingeführt wird. Die Profilkonzepte verwenden Profilidentifikatoren, um verschiedene Profile zu trennen, die verwendet werden, wenn das Komprimierungsschema aufgebaut wird. Alle Variationen und Parameter des Kopfabschnittkomprimierungsschema, die nicht Teil des Kontextzustands sind, werden durch verschiedene Profilidentifikatoren gehandhabt.
Bormann (Herausgeber) [Seite 11]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
(Notiz des Herausgeber: Das Profilkonzept ist noch nicht vollendet – dieser Text basiert auf dem aktuellen Zustand des vorliegenden Dokuments).
Paket
Allgemein eine Einheit des Sendens und des Empfangs (Protokolldateneinheit). Insbesondere im Kontrast zu "Rahmen", das Paket, das durch die ROHC komprimiert und dann dekomprimiert wurde. Auch genannt "nicht komprimiertes Paket".
Vor-HC-Verbindungen
Vor-HC-Verbindungen sind alle Verbindungen, die ein Paket vor dem Punkt der Kopfabschnittkomprimierung durchquert hat. Wenn wir einen Weg mit zellularen Verbindungen als ersten und letzten Sprung betrachten, so sind die Vor-HC-Verbindungen für den Komprimierer auf der letzten Verbindung die erste zellulare Verbindung plus die drahtgebundenen Verbindungen dazwischen.
Restfehler
Fehler, die während der Übertragung eingeführt und nicht durch Fehlererkennungsschemata einer unteren Schicht erkannt werden.
Robustheit
Die Leistung eines Kopfabschnittkomprimierungsschemas kann mit drei Parametern beschrieben werden: Komprimierungseffizienz, Robustheit und Komprimierungstransparenz. Ein robustes Schema toleriert Fehler auf der Verbindung, über der die Kopfabschnittkomprimierung stattfindet (die sowohl Rahmenverluste als auch Restbitfehler einschließt), ohne zusätzliche Pakete zu verlieren, zusätzliche Fehler einzuführen oder mehr Bandbreite zu verwenden.
RTT
Round-trip time – Umlaufzeit. Die Zeit, die es braucht, um ein Paket vom Komprimierer zum Dekomprimierer und zurück wieder vom Dekomprimierer zum Komprimierer zu senden.
Simplexverbindung
Eine Simplexverbindung (oder unidirektionale Verbindung) ist eine Punkt-zu-Punkt-Verbindung ohne einen Rückkanal. Über Simplexverbindungen muss sich die Kopfabschnittkomprimierung auf periodisches Auffrischen verlassen, da eine Rückkopplung vom Dekomprimierer an den Komprimierer nicht gesendet werden kann.
Bormann (Herausgeber) [Seite 12]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2040
Spektrumseffizienz
Funkressourcen sind begrenzt und teuer. Somit müssen sie effizient verwendet werden, um das System ökonomisch brauchbar zu machen. In zellularen Systemen wird dies erzielt, indem die Anzahl der Benutzer, die innerhalb einer Zelle bedient werden, maximiert wird, während die Qualität der gelieferten Dienste auf einem akzeptablen Niveau gehalten wird. Eine Konsequenz einer wirksame Verwendung des Spektrums ist eine hohe Fehlerrate (Rahmenverlust und Restbitfehler), sogar nach einer Kanalkodierung mit einer Fehlerkorrektur.
Zeitstempelschritt
Der Zeitstempelschritt (TS SCHRITT) ist die Zunahme im Wert des Zeitstempels zwischen zwei aufeinanderfolgenden Paketen.
Bormann (Herausgeber) [Seite 13]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
3. Hintergrund
Dieses Kapitel liefert einen Hintergrund für den Gegenstand der Kopfabschnittkomprimierung. Die grundlegenden Ideen werden zusammen mit Beschreibungen der existierenden Schemata zur Kopfabschnittkomprimierung, ihrer Nachteile und ihrer Anforderungen und der Motivation für neue Lösungen einer Kopfabschnittkomprimierung beschrieben.
3.1 Grundlagen der Kopfabschnittkomprimierung
Der Hauptgrund, warum eine Kopfabschnittkomprimierung überhaupt durchgeführt werden kann, ist die Tatsache, dass es eine signifikante Redundanz zwischen Kopfabschnittsfeldern gibt, die sich beide in demselben Paketkopf abschnitt befinden, aber insbesondere zwischen aufeinanderfolgenden Paketen, die zum selben Paketstrom gehören. Durch das Senden einer statischen Feldinformation nur zu Anfang und der Verwendung von Abhängigkeiten und der Vorhersagbarkeit für andere Felder kann die Größe des Kopfabschnitts für die meisten Pakete signifikant reduziert werden.
Im allgemeinen halten Verfahren zur Kopfabschnittskomprimierung einen Kontext aufrecht, bei dem es sich im wesentlichen um die nicht komprimierte Version des letzten Kopfabschnitts handelt, der über die Verbindung gesendet wurde, plus einiger zusätzlicher Information sowohl am Komprimierer als auch am Dekomprimierer. Die Komprimierung und die Dekomprimierung wird relativ zum Kontext durchgeführt. Wenn komprimierte Kopfabschnitte Unterschiede gegenüber dem vorherigen Kopfabschnitt enthalten, wird jeder komprimierte Kopfabschnitt den Kontext des Dekomprimierers aktualisieren. In diesem Fall wird, wenn ein Paket zwischen dem Komprimierer und dem Dekomprimierer verloren geht, der Kontext des Dekomprimierers aus der Synchronisation gebracht, da er nicht korrekt aktualisiert wird. Ein Verfahren zur Kopfabschnittkomprimierung muss einen Weg haben, nach solchen Ereignissen den Kontext zu reparieren, das heißt ihn in Synchronisation zu bringen.
3.2 Existierende Schemata zur Kopfabschnittskomprimierung
Das ursprüngliche Schema zur Kopfabschnittskomprimierung CTCP (VJHC) wurde von Van Jacobson erfunden. Das CTCP komprimiert den 40 Oktett IP + TCP-Kopfabschnitt auf 4 Oktetts. Der CTCP-Komprimierer erkennt Rückübertragungen der Transportschicht und sendet einen Kopfabschnitt, der den Kontext komplett aktualisiert, wenn sie auftauchen. Dieser Reparaturmechanismus benötigt keine explizite Signalisierung zwischen Komprimierer und Dekomprimierer.
Ein allgemeines IP Kopfabschnittskomprimierungsschema, die IP-Kopfabschnittskomprimierung (IPHC), verbessert das CTCP etwas und kann beliebige IP, TCP und UDP-Kopfabschnitte komprimieren. Wenn sie Nicht-TCP-Kopfabschnitte komprimiert, verwendet die IPHC keine Deltakodierung und ist robust. Wenn sie TCP komprimiert, dann wird der Reparaturmechanismus des CTPC verbessert durch ein Nichtbestätigungsschema auf Verbindungsebene, das die Reparatur beschleunigt. Die IPHC komprimiert keine RTP-Kopfabschnitte.
CRTP (CRTP, IPHC) von Casner und Jacobson ist ein Schema der der Kopfabschnittskompresion, das 40 Oktette von IPv4/UDP/RTP-Kopfabschnitten auf ein Minimum von 2 Oktetten komprimiert, wen keine UDP-Prüfsumme vorhanden ist. Wenn die UDP-Prüfsumme vorhanden ist, beträgt der minimale CRTP-Kopfabschnitt 4 Oktette.
Bormann (Herausgeber) [Seite 14]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
CRTP kann nicht denselben Reparaturmechanismus wie CTCP verwenden, da das UDP/RTP keine wiederholte Übertragung durchführt. Stattdessen verwendet CRTP explizite Signalisiernachrichten vom Dekomprimierer zum Komprimierer, die KONTEXT_ZUSTAND-Nachrichten genannt werden, um anzuzeigen, dass der Kontext sich außer Synchronisation befindet. Die Verbindungsumlaufzeit wird somit die Geschwindigkeit dieses Kontextreparaturmechanismus beschränken.
Auf verlustbehafteten Verbindungen mit langen Umlaufzeiten, wie auf den meisten zellularen Verbindungen, funktioniert CRTP nicht gut. Jedes verlorene Paket über der Verbindung bewirkt, dass mehrere nachfolgende Pakete verloren gehen, da sich der Kontext während mindestens einer Verbindungsumlaufzeit außer Synchronisation befindet. Dieses Verhalten ist dokumentiert in [CRTPC]. Bei Sprachübertragungen werden solche langen Verlustereignisse die Sprachqualität verschlechtern. Darüber hinaus wird Bandbreite vergeudet durch die große Kopfabschnitte, die von CRTP beim Aktualisieren des Kontext gesandt werden. [CRTPC] hat herausgefunden, dass CRTP auf einer verlustbehafteten zellularen Verbindung nicht gut genug funktioniert. Es ist klar, dass CRTP alleine kein brauchbares Schema für eine Kopfabschnittkomprimierung für IP-Telephonie über zellulare Verbindungen ist.
Um einen Verlust von Paketen, weil sich der Kontext außer Synchronisation befindet, zu vermeiden, können CRTP-Dekomprimierer versuchen, den Kontext lokal unter Verwendung eines Mechanismus, der als TWICE bekannt ist, zu reparieren. Jedes CRTP-Paket enthält einen Zähler, der für jedes Paket, das vom CRTP-Komprimierer ausgesandt wird, um eins inkrementiert wird. Wenn der Zähler um mehr als eins zunimmt, wurde zumindest ein Paket auf der Verbindung verloren. Der Dekomprimierer versucht dann, den Kontext zu reparieren, indem er schätzt, wie das oder die verlorenen Pakete ihn aktualisiert hätten. Die Schätzung wird dann verifiziert durch das Dekomprimieren des Pakets und das Prüfen der UDP-Prüfsumme – wenn es gelingt, wird die Reparatur als erfolgreich angesehen, und das Paket kann weitergegeben oder geliefert werden. TWICE hat seinen Namen aus der Beobachtung erhalten, dass wenn der komprimierte Paketstrom regelmäßig ist, die korrekte Schätzung darin besteht, die Aktualisierung im aktuellen Paket zweimal auszuführen. [CRTPC] hat herausgefunden, dass sogar mit TWICE CRTP die Anzahl der verlorenen Pakete verdoppelt. TWICE verbessert die CRTP-Leistung signifikant. Es gibt jedoch mehrere Probleme bei der Verwendung von TWICE:

1) Es wird obligatorisch, die UDP-Prüfsumme zu verwenden:
– die minimale komprimierte Kopfabschnittsgröße erhöht sich um 100 auf 4 Oktette.
– die meisten Sprach-Kodierer-Dekodierer, die für zellulare Verbindungen entwickelt wurden, tolerieren Fehler in den kodierten Daten. Solche Kodierer-Dekodierer werden eine Aktivierung der UDP-Prüfsumme nicht wollen, da sie wollen, dass beschädigte Pakete geliefert werden.
– Fehler in den Nutzdaten werden zu einem Versagen der UDP-Prüfsumme führen, wenn die Schätzung korrekt ist (und es kann sein, dass sie erfolgreich ist, wenn sie falsch ist).
2) Der Verlust in einem RTP-Strom, der vor dem Komprimierungspunkt auftritt, wird die Aktualisierungen in den CRTP-Kopfabschnitten weniger regelmäßig machen. Einfache Versionen von TWICE werden dann schlecht funktionieren. Anspruchsvollere Versionen würden für einen Erfolg mehr Reparaturversuche benötigen.

3.3 Anforderungen an das neue Schema für eine Kopfabschnittskomprimierung
Das Hauptproblem bei CRTP besteht darin, dass es gegenüber Paketen, die zwischen dem Komprimierer und dem Dekomprimierer beschädigt werden, nicht ausreichend robust ist. Ein brauchbares Schema für eine Kopfabschnittkomprimierung muss weniger fragil sein. Diese erhöhte Robustheit muss ohne eine Erhöhung der Größe des komprimierten Kopfabschnitts erhalten werden; ein größerer Kopfabschnitt würde die IP-Telephonie über zellulare Verbindungen ökonomisch unattraktiv machen.
Ein Hauptgrund für die schlechte Leistung des CRTP über zellularen Verbindungen besteht in der langen Verbindungsumlaufzeit, während der viele Pakete verloren gehen, wenn der Kontext sich außer Synchronisation befindet. Dieses Problem kann direkt angegangen werden durch das Herausfinden von Wegen zur Reduzierung der Umlaufzeit der Verbindung. Zukünftige Generationen von zellularen Technologien können tatsächlich geringere Verbindungsumlaufzeiten erzielen. Diese werden jedoch immer ziemlich hoch sein [CELL]. Die Vorteile im Hinblick auf den geringeren Verlust und die geringeren Anforderungen an die Bandbreite, wenn der Kontext lokal repariert werden kann, werden vorhanden sein, sogar wenn die Umlaufzeit der Verbindung erniedrigt wird. Ein zuverlässiger Weg, um eine erfolgreiche Reparatur des Kontext zu erkennen, wird somit benötigt.
Man mag argumentieren, dass eine bessere Lösung des Problems darin besteht, die zellulare Verbindung zu verbessern, so dass ein Paketverlust weniger wahrscheinlich auftritt. Solche Modifikationen scheinen aber nicht kostenlos zu sein. Wenn Verbindungen (nahezu) fehlerfrei gemacht würden, könnte es sein, dass das System nicht fähig ist, eine ausreichend große Anzahl von Benutzern pro Zelle zu unterstützen und es somit ökonomisch unbrauchbar ist [CELL].
Man mag auch argumentieren, dass die Sprach-Kodierer-Dekodierer fähig sein sollten, mit der Art des Paketverlustes, der vom CRTP verursacht wird, fertig zu werden, insbesondere da die Sprach-Kodierer-Dekodierer wahrscheinlich fähig sein müssen, sowieso mit einem Paketverlust fertig zu werden, wenn der RTP-Strom das Internet quert. Während letzteres wahr ist, ist die Art des Verlustes, die durch CRTP verursacht wird, schwierig zu handhaben. Es ist gewöhnlicherweise nicht möglich, ein Verlustereignis vollständig zu verbergen, wenn über 100 ms des Tons vollständig verloren gehen. Wenn ein solcher Verlust häufig an beiden Enden des Ende-zu-Ende-Wegs auftaucht, wird die Sprachqualität leiden.
Eine detaillierte Beschreibung der Anforderungen, die für ROHC spezifiziert sind, kann man in [REQ] finden.
3.4 Klassifikation der Kopfabschnittsfelder
Wie früher erwähnt wurde, ist die Kopfabschnittkomprimierung möglich durch die Tatsache, dass es viel Redundanz zwischen Feldwerten des Kopfabschnitts innerhalb von Paketen, aber insbesondere zwischen aufeinanderfolgenden Paketen gibt. Um diese Eigenschaften für die Kopfabschnittkomprimierung zu verwenden, ist es wichtig, die sich ändernden Muster der verschiedenen Kopfabschnittsfelder zu verstehen.
Bormann (Herausgeber) [Seite 16]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Alle Kopfabschnittsfelder wurden im Detail im Anhang A klassifiziert. Die Felder werden zuerst auf einer hohen Ebene klassifiziert und dann werden einige von ihnen detaillierter studiert. Schließlich schließt der Anhang mit Empfehlungen, wie die verschiedenen Felder durch die Algorithmen zur Kopfabschnittskomprimierung gehandhabt werden sollten. Der Hauptschluss, der gezogen werden kann, ist der, dass die meisten Kopfabschnittsfelder leicht komprimiert werden können, da sie sich nie oder selten ändern. Nur 5 Felder mit einer kombinierten Größe von ungefähr 10 Oktetten erfordern anspruchsvollere Mechanismen. Solche Felder sind:

– IPv4 Identifikation (16 Bits) – IP-ID

– UDP-Prüfsumme(16 Bits)

– RTP-Markierung (1 Bit) – M-Bit

– RTP-Sequenznummer (16 Bits) – SN

– RTP-Zeitstempel (32 Bits) – TS
Die Analyse in Anhang A zeigt, dass die Werte der TS- und IP-ID-Felder gewöhnlicherweise aus der RTP-Sequenznummer, die sich für jedes Paket, das von einer RTP-Quelle ausgesandt wird, um eins erhöht, vorhergesagt werden können. Das M-Bit ist gewöhnlicherweise auch dasselbe, aber es muss gelegentlich explizit übertragen werden. Die UDP-Prüfsumme sollte nicht vorhergesagt werden und wird, so wie sie ist, gesendet, wenn sie aktiviert wird.
Die Art, in der die ROHC RTP Komprimierung arbeitet, besteht dann darin, zuerst Funktionen aus der SN und den anderen Feldern zu errichten, und dann die SN zuverlässig zu übertragen. Immer wenn sich eine Funktion von der SN zu einem anderen Feld ändert, das heißt, die existierende Funktion ergibt ein Ergebnis, das sich vom Feld im Kopfabschnitt, das komprimiert werden soll, unterscheidet, wird zusätzliche Information gesendet, um die Parameter dieser Funktion zu aktualisieren.
Bormann (Herausgeber) [Seite 17]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
4. Grundlagen der Kopfabschnittskomprimierung
4.1 Annahmen für den Betrieb
Die zellularen Verbindungen, die ein primäres Ziel für die ROHC sind, weisen eine Anzahl von Eigenschaften auf, die hier kurz beschrieben werden. Die ROHC erfordert eine Funktionalität von niedrigeren Schichten, die hier ausgeführt wird und ausführlicher im Anforderungsdokument für die niedrige Schicht [LLG] beschrieben ist.
Kanäle
ROHC kopfabschnittskomprimierte Pakete fließen auf Kanälen. Im Gegensatz zu den meisten festen Verbindungen können einige zellulare Funkverbindungen mehrere Kanäle aufweisen, die dasselbe Paar von Knoten verbinden. Jeder Kanal kann andere Eigenschaften im Hinblick auf die Fehlerrate, die Bandbreite etc, haben.
Kontextidentifikatoren
Auf einigen Kanälen ist die Fähigkeit, mehrere Paketströme zu transportieren, gefordert. Es kann auch möglich sein, Kanäle zu haben, die einzelnen Paketströme zugewiesen sind. Somit verwendet die ROHC einen eindeutigen Kontextidentifikationsraum pro Kanal und eliminiert Kontextidentifikatoren in Kanälen, wo nur ein einzelner Paketstrom komprimiert wird, vollständig.
Pakettypanzeige
Die Pakettypanzeige findet im Kopfabschnittskomprimierungsschema selbst statt. Wenn die Verbindung nicht schon einen Weg zur Anzeige der Pakettypen, die verwendbar sind, aufweist, wie PPP, liefert dies insgesamt kleinere komprimierte Kopfabschnitte. Es kann auch sein, dass es weniger schwierig ist, einen einzelnen Pakettyp als mehrere Typen zuzuweisen, um die ROHC über Verbindungen, wie PPP, laufen zu lassen.
Neuordnung
Es wird nicht angenommen, dass der Kanal zwischen Komprimierer und Dekomprimierer Pakete neu ordnet, das heißt, der Dekomprimierer empfängt Pakete in derselben Reihenfolge, wie der Komprimierer sie sendet. Die Neuordnung vor dem Komprimierungspunkt wird jedoch behandelt.
Paketlänge
Die ROHC ist unter der Annahme gestaltet, dass untere Schichten die Länge eines komprimierten Pakets liefern können. ROHC-Pakete enthalten keine Längeninformation für die Nutzdaten.
Bormann (Herausgeber) [Seite 18]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Feldanordnung
Die Verbindungsschicht muss eine Feldanordnung liefern, um es möglich zu machen, Rahmengrenzen und einzelne Rahmen voneinander zu unterscheiden.
Fehlererkennung/Fehlerschutz
Das ROHC-Schema wurde gestaltet, um mit Restfehlern in den Kopfabschnitten, die an den Dekomprimierer geliefert werden, fertig zu werden. CRCs und Sanityprüfungen werden verhindert, um die Schadensausbreitung zu verhindern oder zu reduzieren. Es wird jedoch empfohlen, dass die unteren Schichten eine Fehlererkennung für ROHC Kopfabschnitte einsetzen und keine ROHC Kopfabschnitte mit einer hohen Restfehlerrate liefern.
Ohne eine harte Grenze der Restfehlerrate, die für die ROHC akzeptabel ist, anzugeben, wird angemerkt, dass für eine Restbitfehlerrate von höchstens 1E-5, das ROHC-Schema gestaltet wurde, die Anzahl der beschädigten Kopfabschnitte nicht zu erhöhen, das heißt, die Anzahl der beschädigten Kopfabschnitte verursacht durch die Schadensausbreitung ist so gestaltet, dass sie geringer als die Anzahl der beschädigten Kopfabschnitte ist, die durch das ROHC-Fehlererkennungsschema erfasst werden.
Aushandlung
Zusätzlich zu den obigen Pakethandhabungsmechanismen muss die Verbindungsschicht einen Weg liefern, um Parameter für die Kopfabschnittskomprimierung auszuhandeln. (Für unidirektionale Verbindungen kann diese Aushandlung außerhalb des Bandes oder sogar a priori durchgeführt werden.
4.2 Dynamik

[[Dieser Abschnitt wird einführenden Text zur dynamischen Zustandsinformation, die in den Protokolleinheiten enthalten ist, die auf dem ROHC-Protokoll laufen, enthalten, beispielsweise welche Parameter bei der Aushandlung pro Kanal errichtet werden, die den Datenstrom bilden (das heißt, wenn man sie ändert, schafft dies einen anderen Datenstrom), und welche Teil des Kontexts pro Datenstrom sind und somit während der Lebensdauer des Datenstroms änderbar.]] Kanalaufbau. (konfiguriert oder ausgehandelt vor der Kanalaufbauzeit) Satz akzeptabler Profile MAX-KOPFABSCHNITT Größe des CID-Raums Datenstromaufbau: (ausgehandelt zur Zeit des Datenstromaufbaus.) Profil. Änderung des Profils bedeutet einen neuen Datenstrom. Kontext pro Datenstrom: (änderbar während der Lebensdauer eines Datenstroms) Bormann (Herausgeber) [Seite 19] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000 Kontext in: Aktueller Wert aller Kopfabschnittsfelder. (aus diesem kann man ableiten, ob ein IPv4-Kopfabschnitt vorhanden ist, ob die UDP-Prüfsumme freigeschaltet ist) Zusätzlicher Kontext nicht im Kopfabschnitt: TS-Schritt IP-ID in Netzwerkbytereihenfolge? IP-ID ist zufällig? Eine Anzahl von alten Referenzkopfabschnitten Komprimierer- & Dekomprimiererzustand

4.3 Komprimier- und Dekomprimierzustände
Die Kopfabschnittkomprimierung mit der ROHC kann als eine Interaktion zwischen zwei Zustandsmaschinen, einer Komprimiermaschine und eine Dekomprimiermaschine, gekennzeichnet werden. Der Komprimierer und der Dekomprimierer haben jeweils drei Zustände, die auf viele Arten in Bezug zueinander stehen, sogar wenn die Bedeutung der Zustände für die zwei Parteien leicht unterschiedlich sind. Beide Maschinen starten im niedrigsten Komprimierungszustand und gehen allmählich zu höheren Zuständen. Die Übergänge müssen zwischen den zwei Maschinen nicht synchronisiert werden, und normalerweise ist der Komprimierer der einzige, der vorübergehend in niedrigere Zustände zurückgehen kann.
Die nachfolgenden Abschnitte präsentieren einen Überblick der Zustandsmaschinen und ihrer jeweiligen entsprechenden Zustände, beginnend mit dem Komprimierer.
4.3.1 Zustände des Komprimierers
Bei der ROHC-Komprimierung sind die drei Zustände des Komprimierers die Zustände der Initiation und Auffrischung (IR), der ersten Ordnung (First Order, FO) und der zweiten Ordnung (Second Order, SO). Der Komprimierer startet im niedrigsten Komprimierungszustand (IR) und geht allmählich zu höheren Komprimierungszuständen. Der Komprimierer wird immer im höchst möglichen Komprimierungszustand arbeiten, unter der Einschränkung, dass der Komprimierer ausreichend darauf vertrauen kann, dass der Dekomprimierer die Information hat, die notwendig ist, um einen Kopfabschnitt zu dekomprimieren, der gemäß diesem Zustand komprimiert wurde.
Entscheidungen über die Übergänge zwischen den verschiedenen Komprimierungszuständen werden vom Komprimierer vorgenommen auf der Basis von:
Bormann (Herausgeber) [Seite 20]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

– Variationen in den Paketkopfabschnitten
– positive Rückkopplung vom Dekomprimierer (Bestätigungen ACKs)
– negative Rückkopplung vom Dekomprimierer (negative ACKs – NACKs)
– periodische Zeitabläufe (wenn keine Rückkopplung vorhanden ist)

Wie die Übergänge durchgeführt werden, ist im Detail im Kapitel 5 für jeden Betriebsmodus erläutert.
4.3.1.1 Zustand der Initiation und Wiederauffrischung (IR)
Der Zweck des IR-Zustands besteht darin, die statischen Teile des Kontexts beim Dekomprimierer zu initialisieren oder sie nach einem Fehler wieder zurückzugewinnen. In diesem Zustand sendet der Komprimierer eine vollständige Kopfabschnittsinformation. Diese umfasst alle statischen und nicht statischen Felder in nicht komprimierter Form plus einiger zusätzlicher Information. Diese Wiederauffrischungen können auch nur mit der nicht statischen Information durchgeführt werden.
Der Komprimierer sollte im IR-Zustand bleiben, bis er sich ziemlich sicher ist, dass der Dekomprimierer die Information korrekt empfangen hat.
4.3.1.2 Zustand erster Ordnung (FO)
Der Zweck des FO-Zustands besteht darin, Unregelmäßigkeiten im Paketdatenstrom effizient zu übertragen. Wenn der Komprimierer in diesem Zustand arbeitet, sendet er kaum eine vollständige Information, und die gesendete Information ist gewöhnlicherweise zumindest teilweise komprimiert. Der Unterschied zwischen IR und FO sollte somit klar sein.
Der Komprimierer tritt in diesen Zustand ein, wenn die Kopfabschnitte des Paketdatenstroms nicht ihren vorherigen Mustern entsprechen, und er bleibt dort, bis er darauf vertrauen kann, dass der Dekomprimierer alle Parameter des neuen Musters erworben hat. Felder, die immer unregelmäßig sind, erfordern keinen FO, da sie in allen Paketen übertragen werden müssen und sie somit einen Teil darstellen von etwas, das ein gleichförmiges Muster ist.
Da Pakete, die im FO-Zustand gesendet werden, gewöhnlicherweise Kontextaktualisierungsinformation befördern, kann eine erfolgreiche Übertragung der FO-Information von vitaler Bedeutung für eine erfolgreiche Dekomprimierung nachfolgender Pakete sein. Das Dekomprimierungsverfahren ist empfindlich gegenüber Verlust oder Beschädigungen von durchlaufenden FO-Paketen.
4.3.1.3. Zustand zweiter Ordnung (SO)
Dies ist der Zustand, bei dem die Komprimierung optimal ist. Der Komprimierer tritt in den SO-Zustand ein, wenn der zu komprimierende Kopfabschnitt bei gegebener Sequenznummer vollständig vorhersagbar ist, und wenn der Komprimierer ausreichend darauf vertrauen kann, dass der Dekomprimierer alle Parameter der Funktionen von der SN zu anderen Feldern erworben hat. Pakete, die im SO-Zustand gesendet werden, sind nahezu unabhängig voneinander, und die Fehlerempfindlichkeit ist somit niedrig.
Bormann (Herausgeber) [Seite 21]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Die erfolgreiche Dekomprimierung von Paketen, die im SO-Zustand gesendet werden, erfordert jedoch, dass die Information, die in Operationen im vorhergehenden FO-Zustand gesendet wurde, vom Dekomprimierer erfolgreich empfangen wurde.
Die Menge der Information, die im SO-Zustand gesendet wird, ist gewöhnlicherweise fest. Sie kann jedoch langfristig variieren, da der Komprimierer entscheiden kann, die im SO-Zustand zu sendende Informationsmenge zu erhöhen unter Verwendung eines anderen, größeren Kopfabschnittsformats. Die Grundbedingung ist jedoch, dass Pakete, die im SO-Zustand gesendet werden, für die Dekomprimierung nahezu unabhängig voneinander sein müssen.
Der Komprimierer verlässt diesen Zustand und geht zurück zum FO-Zustand, wenn der Kopfabschnitt nicht länger dem gleichförmigen Muster entspricht und nicht auf der Basis vorheriger Kontextinformation unabhängig komprimiert werden kann.
4.3.2 Zustände des Dekomprimierers
Der Dekomprimierer startet in seinem niedrigsten Komprimierungszustand, "Kein Kontext" und geht allmählich zu höheren Zuständen über. Die Dekomprimierzustandsmaschine verlässt normalerweise niemals den Zustand "voller Kontext", wenn sie einmal begonnen hat, in diesem Zustand zu arbeiten.
Wenn der Dekomprimierer anfänglich im Zustand "kein Kontext" arbeitet, so hat er niemals erfolgreich irgend ein Paket dekomprimiert. Wenn ein Paket einmal korrekt dekomprimiert wurde (nach dem Empfang eines Initialisierungspakets mit beispielsweise statischer und dynamischer Information), kann der Dekomprimierer den ganzen Weg bis zum Zustand "voller Kontext" zurücklegen, und auf wiederholte Fehler hin, wird er wieder zurück zu niedrigeren Zuständen gehen. Wenn dies passiert, geht er jedoch zuerst in den Zustand "statischer Kontext" zurück. Dort ist der Empfang eines FO-Pakets normalerweise ausreichend, um einen Übergang wieder in den Zustand "voller Kontext" zu ermöglichen. Nur wenn die Dekomprimierung mehrerer FO-Pakete im Zustand "statischer Kontext" misslingt, wird der Dekomprimierer den ganzen Weg zurück zum Zustand "kein Kontext" gehen.
Wann Zustandsübergange durchgeführt werden, ist im Detail im Kapitel 5 erläutert.
4.4 Betriebsarten
Das ROHC-Schema weist drei Betriebsarten auf, die unidirektionaler Modus, bidirektionaler optimistischer Modus und bidirektionaler zuverlässiger Modus genannt werden.
Bormann (Herausgeber) [Seite 22]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Es ist wichtig, den Unterschied zwischen den Zuständen, wie sie im vorherigen Kapitel beschrieben wurden, und den Betriebsarten zu verstehen, da sie Abstraktionen, die orthogonal zueinander sind, sind. Die Zustandsabstraktion ist dieselbe für alle Betriebsarten, während jeder Modus seine spezifischen Wege hat, um in den verschiedenen Zuständen zu arbeiten und Entscheidungen über die Übergänge zwischen den Zuständen zu fällen.
In welchem Modus zu arbeiten ist, hängt von der Umgebung ab, in der die Komprimierung unter Berücksichtigung von Verbindungsparametern, wie Rückkoppelungsfähigkeiten, Fehlerwahrscheinlichkeiten und Verteilungen, Effekte der Variation der Kopfabschnittsgröße etc. durchzuführen ist. Alle ROHC-Implementierungen müssen alle drei Betriebsarten implementieren und unterstützen. Die drei Betriebsarten werden in den folgenden Unterabschnitten kurz beschrieben.
Detaillierte Beschreibungen der drei Betriebsarten im Hinblick auf die Komprimierungs- und Dekomprimierungslogik werden im Kapitel 5 angegeben. Die Modusübergangsmechanismen werden auch im Kapitel 5 beschrieben.
4.4.1 Unidirektionaler Modus – U-Modus
Wenn man sich im unidirektionalen Betriebsmodus befindet, werden die Pakete nur in einer Richtung, vom Komprimierer zum Dekomprimierer, gesendet. Dieser Modus ermöglicht somit eine ROHC, die über Verbindungen verwendbar ist, bei denen ein Rückpfad vom Dekomprimierer zum Komprimierer nicht verfügbar oder unerwünscht ist.
Im U-Modus werden Übergänge zwischen den Zuständen des Komprimierers nur auf der Basis periodischer Zeitabläufe und Unregelmäßigkeiten in den Kopfabschnittsfeldänderungsmustern im komprimierten Paketdatenstrom durchgeführt. Durch die periodischen Wiederauffrischungen und dem Fehlen der Rückkopplung für die Initiierung einer Fehlerbehebung, wird die Komprimierung im unidirektionalen Modus wenig effizient sein und eine leicht höhere Wahrscheinlichkeit für eine Verlustausbreitung im Vergleich zu irgend einer der bidirektionalen Betriebsarten haben.
Die Komprimierung mit der ROHC muss im unidirektionalen Modus starten. Ein Übergang zu irgend einer der bidirektionalen Betriebsarten kann durchgeführt werden, sobald ein Paket den Dekomprimierer erreicht hat und er mit einem Rückkopplungspaket geantwortet hat, das anzeigt, dass ein Modusübergang gewünscht ist (siehe Kapitel 5).
Bormann (Herausgeber) [Seite 23]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
4.4.2. Bidirektionaler optimistischer Modus – O-Modus
Der bidirektionale optimistische Modus ist ähnlich dem unidirektionalen Modus. Der Unterschied besteht darin, dass ein Rückkopplungskanal verwendet wird, um Fehlerbehebungsanforderungen und (wahlweise) Bestätigungen signifikanter Kontextaktualisierungen vom Dekomprimierer an den Komprimierer zu senden (nicht nur für Sequenznummernaktualisierungen). Periodische Wiederauffrischungen werden im bidirektionalen optimistischen Modus nicht verwendet.
Der O-Modus ist gestaltet für eine optimale Komprimierungseffizienz und einen sparsamen Gebrauch des Rückkanals, während eine vernünftige Robustheit aufrecht gehalten wird. Der Verlust der Komprimierer-Dekomprimierer-Synchronisation und die Einführung einer Verlustausbreitung ist selbst unter hohen Fehlerraten selten. Wenn eine Verlustausbreitung stattfindet, ist die Größe ziemlich unbedeutend. Nichtsdestotrotz ist dieser Modus nicht komplett robust, und bei extrem hohen Fehlerraten kann eine Verlustausbreitung auftreten.
4.4.3 Bidirektionaler zuverlässiger Modus – R-Modus
Der bidirektionale zuverlässige Modus unterscheidet sich auf viele Arten von den zwei vorherigen. Die wichtigsten Differenzen im Hinblick auf die Implementierung und Funktionalität bestehen in einer intensiveren Verwendung des Rückkopplungskanals und einer strengeren Logik sowohl am Komprimierer als auch am Dekomprimierer. Eine Rückkopplung wird gesendet, um alle Kontextaktualisierungen, die Aktualisierungen des Sequenznummernfeldes einschließen, zu bestätigen. Nicht jedes Paket aktualisiert jedoch den Kontext im zuverlässigen Modus.
Der Hauptvorteil des R-Modus besteht in der nahezu vollständigen Robustheit gegenüber einem Paketverlust zwischen dem Komprimierer und dem Dekomprimierer. Eine Verlustausbreitung kann niemals durch eine Kopfabschnittkomprimierung auftreten, wenn man in diesem Modus arbeitet. Der Preis ist ein leicht höherer Overhead in einigen Fällen und der zusätzlich eingeführte Rückkoppelungsverkehr.
4.5 Kodierverfahren
Dieses Kapitel beschreibt die Kodierverfahren, die für verschiedene Kopfabschnittsfelder verwendet werden. Wie diese Verfahren auf jedes Feld (beispielsweise Werte der zugehörigen Parameter) angewandt werden, ist im Kapitel Paketformat spezifiziert.
4.5.1. Kodierung mit den niederwertigsten Bits (LSB)
Die Kodierung mit den niederwertigsten Bits (LSB) wird für Kopfabschnittfelder verwendet, deren Werte normalerweise nur Gegenstand kleiner Änderungen sind. Bei der LSB-Kodierung werden die k niederwertigsten Bits des Feldwerts statt dem ursprünglichen Feldwert übertragen, wobei k eine positive ganze Zahl ist.
Bormann (Herausgeber) [Seite 24]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Nach dem Empfang der k LSBs leitet der Dekomprimierer den ursprünglichen Wert unter Verwendung eines vorher empfangenen Werts als Referenz (v ref) ab.
Dieses Schema ist garantiert korrekt, wenn der Komprimierer und der Dekomprimierer sich über ein Interpretationsintervall einig sind

1) in welchem sich der ursprüngliche Wert befindet, und
2) in welchem der ursprüngliche Wert der einzige Wert ist, der die exakt gleichen k LSBs hat, wie die die übertragen wurden.

Das Interpretationsintervall kann als eine Funktion f(v_ref, k) beschrieben werden. Es sei f(v_ref, k) = [v_ref – p, v_ref + (2^k – 1) – p]wobei p eine ganze Zahl ist.
Die Funktion f hat die folgende Eigenschaft: für jeden Wert k werden k LSBs eindeutig einen Wert in f(v_ref, k) identifizieren. Dies erfüllt die obige Bedingung 2).
Der Parameter p wird eingeführt, so dass das Interpretationsintervall in Bezug auf v_ref verschoben werden kann. Das Wählen eines guten Werts für p wird zu einer effizienteren Kodierung für Felder mit gewissen Eigenschaften führen. Wenn beispielsweise ein Feldwert, der durch den Komprimierer beobachtet wird, immer zunimmt, sollte p auf 0 gesetzt werden, und das Intervall wird [v_ref, v_ref + 2^k – 1]. Da die LSB-Kodierung bei der ROHC auf Kopfabschnittsfelder angewandt wird, deren Werte bis auf ungewöhnliche Situationen zunehmen (wie bei einer Paketfehlordnung oder RTP TS für Video) werden nur zwei Werte p zugeordnet: p1 = 0 oder p2 = 2^(k – 2) – 1. Der letztere ergibt das Interpretationsintervall [v_ref – (2^(k – 2) – 1), v_ref + 3·2^((k – 2)], das kleine negative Änderungen handhaben kann, während es ¾ des Intervalls für positive Änderungen verwendet. Siehe Abschnitt 5.7 für weitere Details.
Das Folgende ist ein vereinfachtes Verfahren für die LSB-Komprimierung und Dekomprimierung. Es wird für eine Robustheit und einen Schutz gegen Schadensausbreitung im nächsten Unterabschnitt modifiziert:

1) Der Komprimierer (Dekomprimierer) verwendet immer v_ref_c (v_ref_d), den letzten Wert, den er komprimiert hat (dekomprimiert hat) als v_ref;
2) Wenn der Komprimierer einen Wert v komprimiert, so berechnet er den minimalen (für die Effizienz) aber ausreichenden (für die Korrektheit) Wert von k, so dass v in das Intervall f(v_ref_c, k) fällt. Dieses Verfahren sei als eine Funktion k = g(v, v_ref) dargestellt. Man beachte, dass mehr als k LSBs gesendet werden können, um zum Paketformat zu passen (siehe Abschnitt Paketformat); Bormann (Herausgeber) [Seite 25] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
3) Wenn der Dekomprimierer m LSBs empfängt, verwendet er das Interpretationsintervall f(v_ref_d, m), genannt Intervall d. Er nimmt als dekomprimierten Wert den einen im Intervall d, dessen LSBs zu den empfangenen m Bits passen.

Das Schema wird durch zwei Faktoren kompliziert: ein Paketverlust zwischen dem Komprimierer und Dekomprimierer und Übertragungsfehler, die von der unteren Schicht nicht erkannt werden. Im ersten Fall werden der Komprimierer und der Dekomprimierer die Synchronisation von v_ref verlieren, und somit auch die des Interpretationsintervalls. Wenn v dennoch durch die Schnittmenge (Intervall c, Intervall d) abgedeckt wird, wird die Dekomprimierung korrekt sein. Ansonsten wird sich eine nicht korrekte Dekomprimierung ergeben. Der nächste Abschnitt wird diesen Gegenstand weiter behandeln.
Im Falle nicht erkannter Übertragungsfehler werden die beschädigten LSBs einen nicht korrekt dekomprimierten Wert ergeben, der später als v_ref_d verwendet wird, was wiederum sehr wahrscheinlich zu einer Schadensausbreitung führt. Dieses Problem wird durch das Verwenden einer Sicherheitsreferenz angegangen, das ist ein Referenzwert, dessen Korrektheit durch einen schützenden CRC verifiziert wird. Somit wird das obige Verfahren 1) folgendermaßen modifiziert:

1) a) Der Komprimierer verwendet als v_ref_c immer den letzten Wert, der komprimiert wurde und der mit einem schützenden CRC gesandt wurde.
b) Der Dekomprimierer verwendet als v_ref_d den letzten korrekten Wert, wie er durch einen folgenden CRC verifiziert ist.

Man beachte, dass im U/O-Modus 1) b) modifiziert wird, so dass wenn die Dekomprimierung unter Verwendung des letzten korrekten Werts misslingt, ein anderer Versuch der Dekomprimierung unternommen wird unter Verwendung des letzten, aber korrekten Werts. Dieses Verfahren dämpft die Schadensausbreitung, wenn ein kleiner CRC einen beschädigten Wert nicht erkennen kann.
4.5.2. Fensterbasierte LSB-Kodierung (W-LSB Kodierung)
Dieser Abschnitt beschreibt, wie der vereinfachte Algorithmus in 4.5.1 zu modifizieren ist, um eine Robustheit zu erzielen.
Es kann sein, dass der Komprimierer nicht den exakten Wert von v_ref_d bestimmen kann, der vom Dekomprimierer für einen speziellen Wert v verwendet wird, da es sein kann, dass einige Kandidaten für v_ref_d verloren gegangen sind oder beschädigt wurden. Durch die Verwendung einer Rückkopplung oder durch das Ausführen vernünftiger Annahmen kann der Komprimierer den Kandidatensatz begrenzen. Der Komprimierer berechnet dann k, unabhängig davon, welches v_ref_d im Kandidatensatz der Dekomprimierer verwendet, wobei v durch das sich ergebende Intervall d abgedeckt wird.
Bormann (Herausgeber) [Seite 26]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Da der Dekomprimierer immer den letzten empfangenen Wert, wo die CRC gelungen ist, als Referenz verwendet, hält der Komprimierer ein gleitendes Fenster (VSW) aufrecht, das die Kandidaten für v_ref_d enthält. Das VSW ist anfangs leer. Die folgenden Operationen werden vom Komprimierer auf dem VSW durchgeführt:

1) Nach dem Senden eines Wertes v (komprimiert oder unkomprimiert), geschützt durch einen CRC, addiert der Komprimierer v zum VSW;
2) Für jeden Wert v, der komprimiert wird, wählt der Komprimierer k = max(g(v, v_min), g(v, v_max)), wobei v_min und v_max der minimale und der maximale Wert im VSW sind, und g die Funktion ist, die im vorherigen Abschnitt definiert wurde;
3) Wenn der Komprimierer ausreichend Vertrauen hat, dass ein gewisser Wert v nicht als Referenz vom Dekomprimierer verwendet wird, wird das Fenster vorgeschoben durch das Entfernen von v und aller Werte älter als v. Das Vertrauen kann durch verschiedene Mittel erreicht werden. Im R-Modus impliziert eine Bestätigung vom Dekomprimierer, dass Werte älter als der bestätigte Wert vom VSW entfernt werden können. Im U/O-Modus gibt es immer einen CRC, um eine korrekte Dekomprimierung zu verifizieren, und es wird ein VSW mit einer begrenzten maximalen Breite verwendet. Die Fensterbreite ist ein Optimierungsparameter, der während der Implementierung bestimmt wird.

Man beachte, dass der Dekomprimierer dem Verfahren folgt, das im vorherigen Abschnitt beschrieben wurde, mit der Ausnahme, dass es im R-Modus jeden Wert, den es mit einem CRC empfängt, bestätigen muss (man nehme für Details Bezug auf den Abschnitt Komprimierungs-/Dekomprimierungs-Logik).
4.5.3 Skalierte RTP-Zeitstempel-Kodierung
Der RTP-Zeitstempel (TS) wird sich gewöhnlicherweise nicht um eine beliebige Zahl von Paket zu Paket erhöhen. Stattdessen ist die Zunahme normalerweise ein integrales Vielfaches einer Einheit (TS_SCHRITT). Im Falle von Audiodaten beträgt die Abtastrate beispielsweise normalerweise 8 kHz, und ein Sprachrahmen kann 20 ms abdecken. Weiterhin wird jeder Sprachrahmen gewöhnlicherweise in einem RTP-Paket befördert. In diesem Fall ist das RTP-Inkrement immer n·160 (= 8000·0,02), für eine ganze Zahl n. Man beachte, dass Stilleperioden keinen Einfluss auf dieses haben, da der Abtasttakt an der Quelle normalerweise weiterläuft ohne ein Ändern der Rahmenrate oder der Rahmengrenzen.
Im Fall von Videodaten, gibt es gewöhnlicherweise ebenfalls einen TS_SCHRITT, wenn wir den Videorahmenpegel betrachten. Die Abtastrate für die meisten Video-Kodierer-Dekodierer beträgt 90 kHz. Wenn die Videorahmenrate fest ist, sagen wir 30 Rahmen/Sekunde, wird der TS sich um n·3000 (= n·90 000/30) zwischen Videorahmen erhöhen. Man beachte, dass ein Videorahmen normalerweise in mehrere RTP-Pakete aufgeteilt wird, um eine Robustheit gegenüber einem Paketverlust zu erzielen. In diesem Fall werden mehrere RTP-Pakete denselben TS tragen.
Wenn eine skalierte RTP-Zeitstempel-Kodierung verwendet wird, wird dieser TS durch einen Faktor des TS_SCHRITTS vor der Komprimierung nach unten skaliert. Dies spart Bits für jeden komprimierten TS. Die folgende Gleichung gilt zwischen TS und TS skaliert:
Bormann (Herausgeber) [Seite 27]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000 TS = TS SKALIERT·TS SCHRITT + TS VERSATZ
TS SCHRITT wird explizit und TS VERSATZ implizit an den Dekomprimierer übertragen. Der folgende Algorithmus wird verwendet:

1. Initialisierung: Der Komprimierer sendet an den Dekomprimierer den Wert von TS_SCHRITT (beispielsweise über eine Inband-Signalisierung, siehe Abschnitt Paketformat) und den absoluten Wert von einem oder mehreren TS. Die letzteren werden vom Dekomprimierer verwendet, um TS_VERSATZ auf (absoluter Wert) modulo TS_SCHRITT zu initialisieren. Man beachte, dass TS_VERSATZ derselbe ist, unabhängig davon welcher absolute Wert verwendet wird, so lange der unskalierte TS-Wert nicht zyklisch wird (wrap around) siehe 4) unten.
2. Komprimierung: Nach der Initialisierung komprimiert der Komprimierer nicht länger mehr die ursprünglichen TS-Werte. Stattdessen komprimiert er die herab skalierten Werte: TS_SKALIERT = TS/TS_SCHRITT. Das Komprimierungsverfahren kann entweder eine W-LSB-Kodierung oder die auf einem Zeitgeber basierende Kodierung, die im nächsten Abschnitt beschrieben wird, sein.
3. Dekomprimierung: Wenn der Dekomprimierer den komprimierten Wert von TS_SKALIERT empfängt, leitet der Dekomprimierer zuerst den Wert des ursprünglichen TS_SKALIERT ab. Der ursprüngliche RTP TS wird dann berechnet als TS = TS_SKALIERT·TS_SCHRITT + TS_VERSATZ.
4. Zyklisch werden: Ein Zyklischwerden des nicht skalierten 32 Bit TS wird den aktuellen Wert von TS_VERSATZ, der in der obigen Gleichung verwendet wird, ungültig machen. Man nehme beispielsweise an, dass TS_SCHRITT = 160 = 0xA0, und der aktuelle TS = 0xFFFFFFF0. TS_VERSATZ ist dann 0x50 = 80. Wenn dann der nächste RTP TS = 0x00000130 ist (das heißt das Inkrement ist 160·2 = 320), sollte der neue TS_VERSATZ sein 0x00000130 modulo 0xA0 = 0x90 = 144. Der Komprimierer muss TS_VERSATZ bei einem Zyklischwerden nicht neu initialisieren. Stattdessen muss der Dekomprimierer das Zyklischwerden des unskalierten TS erkennen (was trivial ist) und TS_VERSATZ aktualisieren auf TS_VERSATZ = (zyklisch geworden um unskalierten TS) modulo TS_SCHRITT

Dieses Skalierverfahren kann auf viele rahmenbasierende Kodierer-Dekodierer angewandt werden. Der Wert von TS_SCHRITT kann sich jedoch während einer Sitzung zum Beispiel durch Adaptionsstrategien ändern. Wenn das passiert, wird der nicht skalierte TS komprimiert, bis die Neuinitialisierung des neuen TS_SCHRITT und TS_VERSATZ vollendet ist.
Bormann (Herausgeber) [Seite 28]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
4.5.4 Auf Zeitgeber basierende Komprimierung des RTP-Zeitstempels
Der RTP-Zeitstempel [RFC 1889] ist definiert, um die Nummer der ersten Abtastung, die verwendet wird, um die Nutzdaten zu erzeugen, zu identifizieren. Wenn RTP-Pakete Nutzdaten befördern, die einem festen Abtastintervall entsprechen, so erfolgt die Abtastung mit einer konstanten Rate, und Pakete werden in einem festen Schritt mit der Abtastung erzeugt, wobei der Zeitstempel einem linearen Muster als eine Funktion der Tageszeit dicht folgen wird. Dies ist der Fall bei interaktiver Sprache. Das lineare Verhältnis wird durch die Quellenabtastrate bestimmt. Das lineare Muster kann durch eine Paketierung kompliziert werden (beispielsweise im Falle von Videodaten, bei denen ein Videobild gewöhnlicherweise mehreren RTP-Paketen entspricht) oder bei einer Bildneuanordnung (beispielsweise werden MPEG B-Frames von einigen Video-Kodierern-Dekodierern außer der Reihenfolge gesendet).
Mit einer festen Abtastrate von 8 kHz sind 20 ms im Zeitbereich äquivalent einem Inkrement von 160 im nicht skalierten TS-Bereich, und einem Inkrement von 1 im skalierten TS-Bereich mit einem TS_SCHRITT = 160.
Als Konsequenz wird der (skalierte) TS von Kopfabschnitten, die zum Dekomprimierer kommen, einem linearen Muster folgen als eine Funktion der Tageszeit, mit einer Abweichung durch eine Verzögerungsschwankung zwischen der Quelle und dem Dekomprimierer. Im normalen Betrieb, das heißt keine Zusammenstöße oder Ausfälle, wird die Verzögerungsschwankung begrenzt, um die Anforderungen von Echtzeit-Sprachverkehr zu erfüllen. Somit kann der Dekomprimierer durch das Verwenden eines lokalen Takts eine Annäherung des (skalierten) TS im Kopfabschnitt, der zu dekomprimieren ist, erhalten, indem er seine Ankunftszeit berücksichtigt. Die Annäherung kann dann mit den k LSBs des (skalierten) TS, die im Anfangsblock transportiert werden, verfeinert werden. Der geforderte Wert von k, um eine korrekte Dekomprimierung zu gewährleisten, ist eine Funktion der Schwankung zwischen der Quelle und dem Dekomprimierer.
Wenn der Komprimierer die potentielle Schwankung, die zwischen dem Komprimierer und dem Dekomprimierer eingefügt wird, kennt, kann er k unter Verwendung eines lokalen Takts bestimmen, um die Schwankung der Paketankunftszeiten zu schätzen, oder er kann alternativ ein festes k verwenden und Pakete verwerfen, die zu stark außer der Zeit ankommen.
Die Vorteile dieses Schemas umfassen:

a) Die Größe des komprimierten TS ist konstant und klein. Insbesondere hängt sie nicht von der Länge der Stilleintervalle ab. Dies steht im Gegensatz zu anderen TS-Komprimierungstechniken, die am Beginn eines Sprachstoßes das Aussenden einer Anzahl von Bits in Abhängigkeit von der Dauer des vorhergehenden Stilleintervalls erfordern.
b) Es ist keine Synchronisation zwischen dem lokalen Takt des Komprimierers und dem lokalen Takt des Dekomprimierers notwendig.

Man beachte, dass obwohl dieses Schema sowohl mit einem skalierten als auch mit einem unskalierten TS zum Arbeiten gebracht werden kann, es in der Praxis vorteilhaft ist, es mit einer skalierten TS-Kodierung zu kombinieren, wegen der weniger strengen Anforderungen an die Taktauflösung, beispielsweise 20 ms statt 1/8 ms. Somit nimmt der unten beschriebene Algorithmus an, dass das taktbasierte Kodierschema auf einem skalierten TS arbeitet. Der Fall des unskalierten TS wird ähnlich sein mit Änderungen in den Skalierungsfaktoren.
Komprimierer: Seine Hauptaufgabe besteht darin, den Wert von k zu bestimmen. Sein gleitendes Fenster TSW enthält nun nicht nur potentielle Referenzwerte für den TS sondern auch ihre Ankunftszeiten am Komprimierer.

1) Der Komprimierer hält ein gleitendes Fenster TSW = {(T_j, a_j), für jeden Kopfabschnitt j der als eine Referenz verwendet werden kann} aufrecht, wobei T_j der skalierte TS für den Kopfabschnitt j ist, und a_j die Ankunftszeit des Kopfabschnitts j ist. Das TSW erfüllt denselben Zweck wie das VSW des Abschnitts 4.5.2.
2) Wenn ein neuer Kopfabschnitt n mit T_n als dem skalierten TS ankommt, notiert der Komprimierer die Ankunftszeit a_n. Dann berechnet er Max_Schwankung_BC = max {|T_n – T_j) – ((a_n – a_j)/ZEIT_SCHRITT|, für alle Kopfabschnitte j im TSW},wobei ZEIT_SCHRITT das Zeitintervall ist, das äquivalent einem TS_SCHRITT ist, beispielsweise 20 ms. Max_Schwankung_BC ist die maximal beobachtete Schwankung vor dem Komprimierer in Einheiten von TS_SCHRITT für die Kopfabschnitte im TSW.
3) k wird berechnet als k = obere Grenze (log2(2·J + 1), wobei J = Max_Schwankung_BC + Max_Schwankung_CD + 2 ist. Max Schwankung CD ist die obere Grenze der Schwankung, die auf dem Kommunikationskanal zwischen dem Komprimierer und dem Dekomprimierer (CD-CC) erwartet wird. Sie hängt nur von den Eigenschaften von CD-CC ab. Der Faktor 2 berücksichtigt den Quantisierungsfehler, der durch die Takte am Komprimierer und Dekomprimierer eingeführt wird, der +/–1 betragen kann. Man beachte, dass die Berechnung von k dem Komprimierungsalgorithmus folgt, der im Abschnitt 4.5.1 beschrieben ist, mit p = 2^(k – 1) – 1.
4) TSW ist Subjekt derselben Fensteroperationen wie im Abschnitt 4.5.2 1) und 3) mit der Ausnahme, dass die Werte, die addiert und entfernt werden, mit ihren Ankunftszeiten gepaart werden

Dekomprimierer:

1) Der Dekomprimierer verwendet als Referenzkopfabschnitt immer den letzten, korrekt dekomprimierten Kopfabschnitt (wie dies durch den CRC verifiziert wird). Er hält das Paar (T_ref, a_ref) aufrecht, wobei T_ref der skalierte TS des Referenzkopfabschnitts ist, und a_ref die Ankunftszeit des Referenzkopfabschnitts ist.
2) Wenn ein komprimierter Kopfabschnitt n zur Zeit a_n empfangen wird, wird die Näherung des ursprünglichen, skalierten TS berechnet als: T_approx = T_Ref + (a_n – a_ref)/ZEIT_SCHRITT
3) Die Näherung wird dann durch die k LSBs, die im Kopfabschnitt n befördert werden, verfeinert, indem man dem Dekomprimieralgorithmus des Abschnitts 4.5.1 folgt, mit p = 2^(k – 1) – 1.

Man beachte, dass der Algorithmus kein spezielles Muster in den Paketen, die am Komprimierer ankommen, annimmt, das heißt, er toleriert eine Neuordnung vor dem Komprimierer und ein nicht zunehmendes Verhalten des RTP-Zeitstempels. Darüber hinaus kann die Taktauflösung schlechter als der ZEIT_SCHRITT sein, wobei in diesem Fall die Differenz, das ist die tatsächliche Auflösung – ZEIT_SCHRITT – als ein zusätzliches Schwanken bei der Berechnung von k behandelt wird.
4.5.4 Versatz IP-ID Kodierung
Dieser Abschnitt nimmt an, dass der IPv4-Stapel an den Quell-Hosts eine IP-ID zum Wert eines 2-Byte Zählers zuweist, der nach jeder Zuweisung an ein nach außen gehendes Paket um eins erhöht wird. Somit wird das IP-ID-Feld eines speziellen IPv4-Paketflusses um 1 von Paket zu Paket inkrementiert, mit der Ausnahme, wenn die Quelle Zwischenpakete ausgegeben hat, die nicht zu diesem Fluss gehören.
Für solche IPv4-Stapel wird die RTP-SN um 1 für jedes Paket zunehmen, und die IP-ID wird um mindestens denselben Betrag zunehmen. Somit ist es effizienter, den Versatz, das heißt (IP-ID – RTP SN), zu komprimieren, statt IP-ID selbst zu komprimieren.
Der folgende Text beschreibt, wie die Sequenz der Versatzwerte unter Verwendung einer W-LSB Kodierung/Dekodierung mit p = 0 zu komprimieren/dekomprimieren ist (siehe Abschnitt 4.5.1).
Komprimierer:
Der Komprimierer verwendet eine W-LSB-Kodierung um eine Sequenz von Versatzwerten zu komprimieren: Versatz i = ID i – SN i,wobei ID i und SN i die Werte von IP-ID und RTP-SN des Kopfabschnitts i sind. Das gleitende Fenster enthält solche Versatzwerte und nicht die Werte der Kopfabschnittsfelder, aber die Regeln für das Addieren und Löschen von Versatzwerten aus dem Fenster folgen ansonsten Abschnitt 4.5.2.
Bormann (Herausgeber) [Seite 31]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Dekomprimierer:
Der Referenzkopfabschnitt ist der letzte korrekt dekomprimierte Kopfabschnitt (wie das durch den CRC verifiziert wird).
Wenn der Dekomprimierer ein komprimiertes Paket m empfängt, so berechnet er Versatz_ref = ID_ref – SN_ref, wobei ID_ref und SN_ref die Werte von IP-ID beziehungsweise RTP SN im Referenzkopfabschnitt sind. Dann wird ein W-LSB-Dekodieren verwendet, um Versatz m zu dekomprimieren, unter Verwendung der empfangenden LSBs im Paket m und dem Versatz_ref. Man beachte, dass m Null-LSBs für den Versatz m enthalten kann, wobei in diesem Fall Versatz m = Versatz_ref.
Schließlich wird die IP-ID für das Paket m wieder hergestellt als IP-ID für m = dekomprimierte SN des Pakets m + Versatz_m.
Man beachte, dass einige IPv4-Stapel das IP-ID-Feld nicht in der Netzwerk-Byte-Reihenfolge übertragen sondern die zwei Oktette umgekehrt senden. In diesem Fall kann der Komprimierer das IP-ID-Feld komprimieren, nachdem er die Bytes ausgetauscht hat. Somit tauscht der Dekomprimierer auch die Bytes der IP-ID nach der Dekomprimierung, um die ursprüngliche IP-ID wieder herzustellen. Dies erfordert, dass der Komprimierer und der Dekomprimierer sich auf der Byte-Reihenfolge des IP-ID-Felds synchronisieren (siehe den Abschnitt über das Kopfabschnittformat).
4.5.6 Unabhängige Variablenlängenwerte
Die Werte von TS_SCHRITT und einigen anderen Komprimierungsparametern können stark variieren. TS_SCHRITT kann 160 für Sprache und 90 000 für 1 f/s Video sein. Um den Transfer solcher Werte zu optimieren, wird eine variable Anzahl von Oktetts verwendet, um diese zu kodieren. Die ersten wenigen Bits des kodierten Werts bestimmen dessen Länge.
1 Oktett: erstes Bit ist null. 7 Bits übertragen. Bis zu 127 dezimal, kodierte Oktette in Hexadezimal: 00 bis 7F
2 Oktette: erste Bits 10. 14 Bits. Bis zu 16 383 dezimal, kodierte Oktette in Hexadezimal: 80 00 bis BF FF
3 Oktette: erste Bits 110. 21 Bits. Bis zu 2 097 152 dezimal, kodierte Oktette in Hexadezimal: C0 00 00 bis DF FF FF
4 Oktette: erste Bits 111. 29 Bits. Bis zu 536 870 912 dezimal, kodierte Oktette in Hexadezimal: E0 00 00 00 bis FF FF FF FF.
4.5.7 Kodierte Werte über mehreren Feldern in komprimierten Kopfabschnitten
Wenn ein komprimierten Kopfabschnitt eine Erweiterung aufweist, so können Stücke eines kodierten Wertes in mehr als einem Feld vorhanden sein. Wenn ein kodierter Wert über mehrere Felder in dieser Weise aufgeteilt wird, so sind die höherwertigen Bits des Werts dichter am Beginn des Kopfabschnitts. Wenn die Anzahl der Bits, die in den komprimierten Kopfabschnittsfeldern verfügbar sind, die Anzahl der Bits des Werts übersteigen, wird das höchstwertigste Feld mit Nullen bei seinen höchstwertigsten Bits aufgefüllt.
Bormann (Herausgeber) [Seite 32]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Beispielsweise kann ein nicht skalierter TS-Wert unter Verwendung eines UOR-2-Kopfabschnitts (siehe Abschnitt 5.7) mit einer Erweiterung des Typs 3 übertragen werden. Das Tsc-Bit der Erweiterung wird dann rückgesetzt (unset), und das TS-Feld variabler Länge der Erweiterung beträgt 4 Oktette (siehe Abschnitt 4.5.6). Das UOR-2 TS-Feld wird die höchstwertigsten drei Bits des unskalierten TS enthalten, und das 4 Oktett TS-Feld in der Erweiterung enthält die verbleibenden 29 Bits.
Bormann (Herausgeber) [Seite 33]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5. Das Protokoll
5.1 Datenstrukturen

[[Anmerkung des Herausgebers: Dieser Abschnitt wird hauptsächlich eine detailliertere, spezifikationsartige Version der einführenden Information in 4.2. sein]]

5.1.1 Parameter pro Kanal
5.1.2 Pro-CID-Parameter, Profile
5.1.3 Kontexte
5.2 Pakettypen
Das ROHC-Schema verwendet sechs Pakettypen, die durch die ersten paar Bits des Kopfabschnitts angezeigt werden. Das Format eines Pakettyps kann vom Modus abhängen. Daher wird ein Namensgebungsschema der Form
<Modusformat ist verwendet in>-<Pakettypnummer>->eine Eigenschaft>
verwendet, um das Format, wenn notwendig, eindeutig zu identifizieren. Beispielsweise UOR-2, R-1. Für die exakten Formate der Pakettypen siehe Abschnitt 5.7.
[Anmerkung von Mikael Degermark – der Rest dieses Abschnitts ist ein Versuch zu beschreiben, welche Pakettypen wann verwendet werden können. Es beginnt als ein Versuch Pakettypen auf eine Art zu gruppieren, die es leichter macht, die folgenden Kapitel zu schreiben. Es ist mir wohl nicht sehr gut gelungen, eine kleine Anzahl von Paketklassen zu finden. Können wir diese Tabelle oder etwas ähnliches definieren. Es würde für eine implementierende Person sehr hilfreich sein. Die Tabelle sollte vielleicht woanders hinbewegt werden ...]
Die folgende Tabelle fasst zusammen, welches Format wann verwendet werden kann. Wenn ein Pakettyp von Klammern umgeben ist, wird die Verwendung dieses Pakettyps die Robustheit erniedrigen. Wenn mehrere Pakettypen angezeigt sind, sollte der kleinste Typ, der den zum komprimierenden Kopfabschnitt darstellen kann, verwendet werden.
Bormann (Herausgeber) [Seite 34]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

* Robustheit wird leiden, wenn nicht ein PT-2 Kopfabschnitt verwendet wird, der das korrekte Ergebnis auch dann ergibt, wenn alte SN-Funktionen verwendet werden.

5.2.1 Paketformate vom Komprimierer zum Dekomprimierer
Vier Pakettypen werden vom Komprimierer zum Dekomprimierer verwendet. Drei für die komprimierten Kopfabschnitte und einer für die Initialisierung/Wiederauffrischung. Kontextidentifikatoren der passenden Länge gehen diesen Kopfabschnitten voraus. Exakte Kopfabschnittformate kann man im Abschnitt 5.7 finden.
Pakettyp null: R-0, R-0-CRC, UO-0
Dieser, der minimale Pakettyp wird verwendet, wenn Parameter aller SN-Funktionen dem Dekomprimierer bekannt sind, und der zu komprimierende Kopfabschnitt an solchen Funktionen haftet. Somit muss nur die W-LSB kodierte RTP SN übertragen werden.
R-Modus: Nur wenn ein CRC vorhanden ist (Pakettyp R-0-CRC) kann der Kopfabschnitt als eine Referenz für die nachfolgende Dekomprimierung verwendet werden.
U-Modus und O-Modus: Eine kleiner CRC ist im UO-0 Paket vorhanden.
Pakettyp 1: R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS.
Dieser Pakettyp wird verwendet, wenn die Anzahl der Bits, die für die SN benötigt werden, solche, die im Pakettyp null verfügbar sind, übersteigt, oder wenn sich die Parameter der SN-Funktionen für RTP TS oder IP-ID ändern.
R-Modus: R-1_* Pakete werden nicht als Referenz für die nachfolgende Dekomprimierung verwendet. Werte für andere Felder als RTP TS oder IP-ID können unter Verwendung einer Erweiterung übertragen werden, aber sie aktualisieren den Kontext nicht.
Bormann (Herausgeber) [Seite 35]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
U-Modus und O-Modus: Nur die Werte von RTP SN, RTP TS und IP-ID können als Referenz für die weitere Komprimierung verwendet werden. Nicht aktualisierende Werte können für andere Felder unter Verwendung einer Erweiterung vorgesehen werden (UO-1-ID).
Pakettyp 2: UOR-2, UOR-2-ID, UOR-2-TS
Dieser Pakettyp kann verwendet werden, um die Parameter jeder SN-Funktion mit der Ausnahme einer solchen für die meisten statischen Felder zu ändern. Kopfabschnitte der Pakete, die unter Verwendung des Pakettyps 2 übertragen werden, können als eine Referenz für eine nachfolgende Dekomprimierung verwendet werden.
Pakettyp 5: IR
Dieser Pakettyp überträgt den statischen Teil des Kontexts, das ist der Wert der konstanten SN-Funktionen. Er kann wahlweise auch den dynamischen Teil des Kontexts, das sind die Parameter der nicht konstanten SN-Funktionen, übertragen.
Pakettyp 6: IR-DYN
Dieser Pakettyp überträgt den dynamischen Teil des Kontexts, das sind die Parameter der nicht konstanten SN-Funktionen.
5.2.2 Rückkopplungspakete vom Dekomprimierer zum Komprimierer
Rückkopplungspakete tragen Information vom Dekomprimierer zum Komprimierer. Die folgenden Arten der Rückkopplung werden unterstützt. Die ersten drei steuern den Zustand und den Modulübergang, und die vierte informiert den Komprimierer darüber, dass der Dekomprimierer nicht genügend Ressourcen aufweist, um einen Paketstrom zu dekomprimieren.
ACK: Bestätigt eine erfolgreiche Dekomprimierung eines Pakets, was bedeutet, dass der Kontext mit hoher Wahrscheinlichkeit aktuell ist.
NACK: Zeigt an, dass der dynamische Kontext des Dekomprimierers außer Synchronisation ist.
STATIC-NACK (Statischer NACK): Zeigt an, dass der statische Kontext des Dekomprimierers nicht gültig ist oder nicht errichtet wurde.
REJECT (Zurückweisung): Zeigt an, dass die Komprimierung dieses Paketstroms durch Beschränkung der Ressourcen nicht unterstützt werden kann.
5.2.3 Benötigte Parameter für den Modusübergang
Der Pakettyp UOR-2 ist allen Modusarten gemeinsam. Er kann eine Erweiterung mit einem Modusparameter tragen, der die Werte U = Unidirektional, O = Bidirektional optimistisch, und R = Bidirektional zuverlässig annehmen kann.
Bormann (Herausgeber) [Seite 36]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Rückkopplungspakete der Typen ACK, NACK und STATIC-NACK trägen Sequenznummern und sie können auch einen Modusparameter tragen, der den gewünschten Komprimierungsmodus anzeigt: U, O oder R.
Als Abkürzung wird die Bezeichnung PACKET(Modus) verwendet, um anzuzeigen, welchen Moduswert ein Paket trägt. Beispielsweise wird ein ACK mit dem Modusparameter R geschrieben als ACK(R), und ein UOR-2 mit dem Modusparameter O wird geschrieben als UOR-2(O).
5.3 Betrieb im unidirektionalen Modus
5.3.1 Zustände und Logik des Komprimierers (U-Modus)
Nachfolgend ist eine Zustandsmaschine für den Komprimierer im unidirektionalen Modus angegeben. Details der Übergange zwischen den Zuständen und der Komprimierlogik werden nach der Figur angegeben.
5.3.1.1 Zustandsübergangslogik (U-Modus)
Die Übergangslogik für die Komprimierzustände im unidirektionalen Modus basiert auf drei Prinzipien: dem Prinzip der optimistischen Näherung, Zeitabläufen und der Notwendigkeit für Aktualisierungen.
5.3.1.1.1. Optimistische Näherung, Aufwärts-Übergang
Der Übergang in einen höheren Komprimierungszustand im unidirektionalen Modus wird gemäß dem Prinzip der optimistischen Näherung ausgeführt. Dies bedeutet, dass der Komprimierer in einen höheren Komprimierungszustand übergeht, wenn er ziemlich sicher ist, dass der Dekomprimierer genügend Information empfangen hat, um korrekt Pakete zu dekomprimieren, die gemäß dem höheren Komprimierungszustand gesendet werden.
Bormann (Herausgeber) [Seite 37]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Wenn sich der Komprimierer im IR-Zustand befindet, wird er dort bleiben, bis er annimmt, dass der Dekomprimierer die statische Kontextinformation korrekt empfangen hat. Für den Übergang vom FO- zum SO-Zustand sollte der Komprimierer sicher sein, dass der Dekomprimierer alle Parameter hat, die benötigt werden, eine Dekomprimierung gemäß einem festen Muster durchzuführen.
Der Komprimier erhält normalerweise seine Sicherheit über den Status des Dekomprimierers, indem er mehrere Pakete mit derselben Information gemäß dem niedrigeren Komprimierungszustand sendet. Wenn der Dekomprimierer irgend eines dieser Pakete empfängt, wird er in Synchronisation mit dem Dekomprimierer sein. Die Anzahl der aufeinanderfolgende Pakete, die für das Erhalten eines vertrauenswürdigen Zustands gesendet werden müssen, ist in diesem Dokument nicht definiert.
5.3.1.1.2. Zeitabläufe, Übergang nach unten
Durch die Verwendung der oben beschriebenen optimistischen Näherung wird es immer eine Möglichkeit für einen Fehler geben, da es sein kann, dass der Dekomprimierer nicht ausreichend Information für eine korrekte Dekomprimierung empfangen hat. Somit muss der Komprimierer periodisch in niedere Komprimierungszustände gehen. Der periodische Übergang in den IR-Zustand sollte weniger oft als der Übergang in den FO-Zustand ausgeführt werden. Es sollten somit zwei verschiedene Zeitabläufe für diese Übergange verwendet werden. Ein Beispiel für die Implementierung periodischer Auffrischung ist im [IPHC] Kapitel 3.3.1–3.3.2. gezeigt.
5.3.1.1.3. Notwendigkeit für Aktualisierungen, Übergang nach unten
Zusätzlich zu den Übergängen nach rückwärts, die während periodischer Zeitabläufe ausgeführt werden, muss der Komprimierer auch sofort in den FO-Zustand zurück gehen, wenn der zu komprimierende Kopfabschnitt das errichtete Muster nicht bestätigt.
5.3.1.2. Komprimierungslogik und verwendete Pakete (U-Modus)
Der Komprimierer wählt das kleinstmögliche Paketformat, das die gewünschten Änderungen übertragen kann, und das die georderten Bits für W-LSB kodierte Werte hat. Gleitende Fenster, die beim W-LSB Kodieren verwendet werden, haben eine feste Breite.
5.3.1.3 Rückkopplung im unidirektionalen Modus
Der unidirektionale Modus des Betriebs ist gestaltet, um über Verbindungen zu arbeiten, bei denen ein Rückkopplungskanal nicht verfügbar ist. Wenn ein Rückkopplungskanal verfügbar ist, kann der Dekomprimierer jedoch eine Bestätigung einer erfolgreichen Dekomprimierung mit einem auf U gesetzten Modusparameter senden (eine ACK(U) senden). Wenn der Komprimierer eine solche Nachricht empfängt, so kann er das Intervall zwischen periodischem IR Auffrischen abschalten oder erhöhen.
Bormann (Herausgeber) [Seite 38]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.3.2. Zustände und Logik des Dekomprimierers (U-Modus)
Unten ist eine Zustandsmaschine für den Dekomprimierer im unidirektionalen Modus angegeben. Details der Übergänge zwischen den Zuständen und der Dekomprimierungslogik werden nach der Figur angegeben.
5.3,2.1 Zustandsübergangslogik (U-Modus)
Die Zustandsübergangslogik des Dekomprimierers ist viel einfacher als die auf der Seite des Komprimierers. Sie ist auch allen drei Betriebsarten gemeinsam. Eine erfolgreiche Dekomprimierung wird den Dekomprimierer immer in den vollen Kontextzustand bewegen. Eine wiederholt fehlgeschlagene Dekomprimierung wird den Dekomprimierer zwingen, zurück in einen niedrigeren Zustand zu gehen. Der Dekomprimierer versucht überhaupt nicht Kopfabschnitte in den Zuständen "Kein Kontext" und "Statischer Kontext" zu dekomprimieren, es sei denn dass ausreichend Information im Paket selbst enthalten ist.
5.3.2.2 Dekomprimierungslogik (U-Modus)
Die Dekomprimierung im unidirektionalen Modus wird in drei Schritten ausgeführt, die in den nachfolgenden Abschnitten beschrieben sind.
5.3.2.2.1. Entscheide, ob Dekomprimierung erlaubt ist
Im Zustand "Voller Kontext" kann eine Dekomprimierung versucht werden unabhängig von der Art des Pakets, das empfangen wird. Für die anderen Zustände ist die Dekomprimierung aber nicht immer erlaubt. Im Zustand "Kein Kontext" können nur IR-Pakete, die die statischen Informationsfelder tragen, dekomprimiert werden. Weiterhin können, wenn man sich im Zustand "Statischer Kontext" befindet, nur Pakete, die einen strengen CRC tragen, dekomprimiert werden (das ist IR, IR-DYN oder UOR-2 Pakete). Wenn die Dekomprimierung nicht durchgeführt werden kann, wird das Paket verworfen, es sei denn, dass der verzögerte Dekomprimierungsmechanismus verwendet wird, siehe Abschnitt x.x.x.
Bormann (Herausgeber) [Seite 39]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.3.2.2.2. Neukonstruktion und Verifizierung des Kopfabschnitts

// TWB basierend auf Kapitel 4.5 LSB Interpretation, Korrektur des zyklisch Werdens Alle dekomprimierten Kopfabschnitte werden mit einem CRC verifiziert

5.3.2.2.2 Gründe für CRC-Fehlanpassungen
Eine Fehlanpassung im 3 Bit CRC kann verursacht werden durch einen oder mehrere der folgenden Punkte:

1. Restbitfehler im aktuellen Kopfabschnitt,
2. ein beschädigter Kontext durch Restbitfehler in vorhergehenden Kopfabschnitten, oder
3. ein Verlust von 16 oder mehr aufeinander folgenden Paketen, die bewirken, dass die 4 Bit SN zyklisch wird (was im wesentlichen eine andere Art einer Kontextbeschädigung darstellt).

Der 3 Bit CRC, der in UO-0 und UO-1 Kopfabschnitten vorhanden ist, wird schließlich zuverlässig eine Kontextbeschädigung erkennen, da die Wahrscheinlichkeit einer nicht erkannten Kontextbeschädigung exponentiell mit jedem neuen verarbeiteten Kopfabschnitt abnimmt. Restbitfehler im aktuellen Kopfabschnitt werden jedoch nur mit einer guten Wahrscheinlichkeit aber nicht zuverlässig erkannt.
Wenn eine CRC-Fehlanpassung durch Restbitfehler im aktuellen Kopfabschnitt (Fall 1 oben) verursacht wird, sollte der Dekomprimierer in seinem aktuellen Zustand bleiben, um einen unnötigen Verlust der nachfolgenden Pakete zu vermeiden. Andererseits kann, wenn die Fehlanpassung durch einen beschädigten Kontext verursacht wird, der Dekomprimierer versuchen, den Kontext zu reparieren, aber wenn er ausfällt, so muss er sich in einen niedrigeren Zustand begeben, um das Liefern nicht korrekter Kopfabschnitte zu vermeiden. Wenn die Fehlanpassung durch einen langen Verlust verursacht wird, kann der Dekomprimierer zusätzliche Dekomprimierungsversuche probieren.

– Langverlustdetektion (Zeitgeber)
– Unkorrekte Korrekturen eines Zyklischwerdens
– Wiederholte Rekonstruktionsversuche im Falle eines langen Verlusts

In den folgenden Abschnitte werden Mechanismen beschrieben, die den Grund für eine CRC-Fehlanpassung detektieren können. Wenn es diesen Mechanismen nicht gelingt, den Grund für die CRC-Fehlanpassung zu finden, so brauchen zusätzliche Dekomprimierungsversuche nicht durchgeführt werden.
Bormann (Herausgeber) [Seite 40]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.3.2.2.4. Detektion einer Kontextbeschädigung
Eine Kontextbeschädigung erhöht die Wahrscheinlichkeit einer CRC-Fehlanpassung. Mit 3-Bit CRCs beträgt die Wahrscheinlichkeit der Detektion des fehlerhaften Kopfabschnitts grob 7/8. Mit 7-Bit und 8-Bit CRCs beträgt die Wahrscheinlichkeit grob 127/128 beziehungsweise 255/256.
Im Zustand "Voller Kontext" bewegt sich, immer wenn die Dekomprimierung der 4 UO-0 oder UO-1 Kopfabschnitte aus den letzten 6 Kopfabschnitten misslungen ist, der Dekomprimierer in den Zustand "Statischer Kontext". Im Zustand "Statischer Kontext" bewegt sich, immer wenn die Dekomprimierung von 2 aus den letzten 3 UOR-2 oder IR-DYN Paketen misslungen ist, der Komprimierer in den Zustand "Kein Kontext". Eine Implementierung kann sich früher in die niedrigeren Zustände bewegen, aber sie sollte nicht später, als das hier spezifiziert ist, in einen niedrigeren Zustand gehen.
[[Anmerkung des Herausgebers: die exakte Zahl benötigt wahrscheinlich mehr Diskussion]]
5.3.2.2.5. Reparatur des Zyklischwerdens der SN
Mindestens 16 Kopfabschnitte müssen verloren gehen, damit die SN der UO-0 oder UO-1 Kopfabschnitte zyklisch wird. Der Dekomprimierer kann diese Situation erkennen, indem er einen lokalen Takt verwendet. Der folgende Algorithmus kann verwendet werden:

a. Der Dekomprimierer notiert die Ankunftszeit a_i jedes herein kommenden Pakets i. Die Ankunftszeiten von Paketen, bei denen die Dekomprimierung misslingt, werden verworfen.
b. Wenn die Dekomprimierung misslingt, so berechnet der Dekomprimierer INTERVALL = a_i – a_i – 1, das heißt die Zeit, die zwischen der Ankunft des vorherigen korrekt dekomprimierten Pakets und des aktuellen Pakets vergeht.
c. Wenn ein Zyklischwerden aufgetreten ist, wird INTERVALL mindestens 16 Zeiten zwischen Paketen entsprechen. Basierend auf einer Schätzung der Paket-Zwischen-Ankunftszeit, die man beispielsweise durch einen gleitenden Querschnitt der Ankunftszeiten TS_SCHRITT oder TS_ZEIT erhält, beurteilt der Dekomprimierer, ob INTERVALL 16 oder mehr Zwischen-Paketzeiten entsprechen kann.
d. Wenn beurteilt wird, dass INTERVALL mindestens 16 Paket-Zwischen-Ankunftzeiten entspricht, addiert der Dekomprimierer 16 zur SN des Kontexts und versucht das Paket unter Verwendung des neuen Kontexts zu dekomprimieren.
e. Wenn diese Dekomprimierung gelingt, aktualisiert der Dekomprimierer den Kontext, sollte das Paket aber nicht an obere Schichten liefern. Das folgende Paket wird auch dekomprimiert und aktualisiert den Kontext, wenn die CRC gelingt, aber es sollte verworfen werden. Wenn die Dekomprimierung des dritten Pakets unter Verwendung des neuen Kontexts auch gelingt, wird angenommen, dass die Kontextreparatur erfolgreich war, und dieses und nachfolgend dekomprimierte Pakete werden an die oberen Schichten geliefert. Bormann (Herausgeber) [Seite 41] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
f. Wenn irgend einer der drei Dekomprimierungsversuche in d. und e. misslingt, verwirft der Dekomprimierer die Pakete und bewegt sich in den Zustand "Statischer Kontext".

Unter Verwendung dieses Mechanismus kann der Dekomprimierer den Kontext nach einem übermäßigen Verlust auf Kosten des Verwerfens von zwei Paketen reparieren.
5.3.2.2.6. Reparatur nicht korrekter SN-Aktualisierungen
Es kann sein, dass es der CRC durch ihre begrenzte Länge nicht gelingt, Restfehler im komprimierten Kopfabschnitt zu detektieren, das heißt, es kann sein, dass das nicht korrekt dekomprimierte Paket denselben CRC wie das ursprüngliche, nicht komprimierte Paket besitzt, was bewirkt, dass das nicht korrekt dekomprimierte Paket akzeptiert wird und der Kontext aktualisiert wird. Dies kann zu einer fehlerhaften Referenz-SN führen, die beim W-LSB-Dekodieren verwendet wird, da die Referenz-SN für jeden erfolgreich dekomprimierten Kopfabschnitt gewisser Typen aktualisiert wird.
Wenn dies passiert, wird der Dekomprimierer die nicht korrekte Dekomprimierung des folgenden Pakets mit hoher Wahrscheinlichkeit erkennen, aber er kennt nicht den Grund für den Fehler. Der folgende Mechanismus erlaubt es dem Dekomprimierer zu beurteilen, ob der Kontext durch ein früheres Paket nicht korrekt aktualisiert wurde.

1) Der Dekomprimierer hält immer zwei dekomprimierte SN: die letzte (ref 0) und die davor (ref –1).
2) Beim Empfangen einer komprimierten SN: SN curr = dekomprimierte SN unter Verwendung von ref 0 als Referenzwert, dekomprimiere den Rest des Kopfabschnitts unter Verwendung von SN curr WENN (der Kopfabschnitt den CRC-Test besteht) ref –1 = ref 0 ref 0 = SN curr
3) SONST SN curr = dekomprimierte SN verwendet ref –1 als Referenzwert, dekomprimiert den Rest des Kopfabschnitts unter Verwendung von SN curr WENN (Kopfabschnitt besteht den CRC-Test) ref 0 = SN curr // beachte ref –1 unverändert
4) SONST // eine von zwei Fehlersituationen: // 1) Bitfehler im aktuellen Kopfabschnitt, // 2) Dekomprimierungskontext beschädigt. Verwende // 5.3.2.2.4 um zu unterscheiden (beispielsweise nehme // an, dass der Kontext beschädigt ist, nur nach k aus // n Fehlern)

Der Zweck dieses Algorithmus besteht darin, den Kontext zu reparieren. Wenn der Kopfabschnitt, der in 3) erzeugt wurde, den CRC-Test besteht, müssen zwei oder mehr Kopfabschnitte auch erfolgreich dekomprimiert werden, bevor angenommen werden kann, dass die Reparatur erfolgreich ist. Von den drei erfolgreichen Kopfabschnitten sollten die ersten zwei verworfen und nur der dritte an die oberen Schichten geliefert werden. Wenn die Dekomprimierung irgend einer der drei Kopfabschnitte misslingt, muss der Dekomprimierer den Kopfabschnitt und die vorher erzeugten Kopfabschnitte verwerfen und sich in den Zustand "Statischer Kontext" begeben.
Bormann (Herausgeber) [Seite 42]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.3.2.3. Rückkopplung im unidirektionalen Modus
Um die Leistung für den unidirektionalen Modus über eine Verbindung, die einen Rückkopplungskanal hat, zu verbessern, kann der Dekomprimierer eine Bestätigung senden, wenn die Dekomprimierung gelingt. Das Setzen des Modusparameters im ACK-Paket auf U zeigt an, dass der Komprimierer im unidirektionalen Modus bleiben soll. Wenn eine ACK(U) empfangen wird, sollte der Komprimierer die Frequenz der IR-Pakete reduzieren, da die statische Information korrekt empfangen wurde, aber er muss das Senden von IR-Paketen nicht stoppen. Wenn weiter IR-Pakete ankommen, kann der Dekomprimierer die ACK(U) wiederholen, aber er sollte die ACK nicht kontinuierlich wiederholen.
Bormann (Herausgeber) [Seite 43]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.4 Betrieb im bidirektionalen optimistischen Modus
5.4.1 Zustände und Logik des Komprimierers (O-Modus)
Unten ist die Zustandsmaschine für den Komprimierer im bidirektionalen optimistischen Modus angegeben. Details jedes Zustands, der Übergänge zwischen den Zuständen und der Komprimierungslogik werden nach der Figur angegeben.
5.4.1.1. Zustandsübergangslogik
Die Übergangslogik für die Komprimierungszustände im bidirektionalen optimistischen Modus hat viel gemeinsam mit der Logik des unidirektionalen Modus. Das optimistische Lösungsprinzip und die Übergänge wegen der Notwendigkeit für Aktualisierungen arbeiten auf dieselbe Weise wie im Kapitel 5.3.1 beschrieben. Im optimistischen Modus gibt es aber keine Zeitabläufe. Stattdessen verwendet der optimistische Modus die Rückkopplung vom Dekomprimierer zum Komprimierer für Übergänge in der Rückwärtsrichtung als auch für einen verbesserten Vorwärtsübergang.
5.4.1.1.1. Kontextanforderungen, negative Bestätigungen (NACKs)
5.4.1.1.2. Optionale Bestätigungen
5.4.1.2. Komprimierungslogik und verwendete Pakete

// Gibt es einen Unterschied gegenüber dem unidirektionalen Modus?? Bormann (Herausgeber) [Seite 44] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

5.4.2. Zustände und Logik des Dekomprimierers
Die Dekomprimierungszustände und die Zustandsübergangslogik sind dieselben wie beim unidirektionalen Fall (siehe Abschnitt 5.3.2). Was sich unterscheidet ist die Dekomprimierungs- und Rückkopplungslogik.
5.4.2.1 Dekomprimierungslogik
5.4.2.1.1. Auf Zeitgeber basierende Zeitstempeldekomprimierung

Beachte: Dieser Mechanismus muss hier beschrieben werden, da er nicht im unidirektionalen Modus verwendet werden kann, da keine Anzeige an den Komprimierer gegeben werden kann, wenn das auf dem Zeitgeber basierende Verfahren misslingt.

5.4.2.2. Rückkopplungslogik
Die Rückkopplungslogik definiert welche Rückkopplungsnachrichten bei verschiedenen Ereignissen zu senden sind, wenn man in den verschiedenen Zuständen arbeitet.
// Beachte: Muss neu geschrieben werden und bezieht sich nicht auf FH, FO und IR Pakete.
Im NC-Zustand:

– Wenn ein FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf 0 gesetzt ist
– Wenn ein FO- oder SO-Paket empfangen wird, oder wenn die Dekomprimierung eines FH-Pakets misslungen ist, sende eine STATIC-NACK, bei der der Modusparameter auf 0 gesetzt ist.

Im SC-Zustand:

– Wenn ein FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf 0 gesetzt ist
– Wenn ein FO-Paket korrekt dekomprimiert wird, sende optional eine ACK, bei der der Modusparameter auf 0 gesetzt ist
– Wenn ein SO-Paket empfangen wird, sende eine NACK, bei der der Modusparameter auf O gesetzt ist
– Wenn die Dekomprimierung eines FO- oder FH-Pakets misslungen ist, sende eine STATIC-NACK, bei der der Modusparameter auf Ogesetzt ist

Im FC-Zustand:

– Wenn ein FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf 0 gesetzt ist
– Wenn ein FO-Paket korrekt dekomprimiert wird, sende optional eine ACK, bei der der Modusparameter auf 0 gesetzt ist
– Wenn ein SO-Paket korrekt dekomprimiert wird, sollte keine Rückkopplung gesendet werden
– Wenn die Dekomprimierung eines SO-, FO- oder FH-Pakets misslungen ist, sende eine NACK, bei der der Modusparameter auf O gesetzt ist.

5.5. Betrieb im bidirektionalen zuverlässigen Modus
5.5.1 Zustände und Logik des Komprimierers
Unten ist eine Zustandsmaschine für den Komprimierer im bidirektionalen zuverlässigen Modus angegeben. Details jedes Zustands, der Übergänge zwischen den Zuständen und der Komprimierungslogik werden nach der Figur gegeben.
// Dieses Kapitel sollte mit Unterkapiteln in einer Weise,
// die mit 5.3 und 5.4 konsistent ist, strukturiert werden.
5.5.2 Zustände und Logik des Dekomprimierers
Die Dekomprimierungszustände und die Zustandsübergangslogik sind dieselben wie im undirektionalen Fall (siehe Abschnitt 5.3.2). Was sich unterscheidet ist die Dekomprimierungs- und Rückkoppelungslogik.
5.5.2.1. Dekomprimierungslogik
5.5.2.2. Rückkoppelungslogik
Die Rückkoppelungslogik definiert, welche Rückkoppelungsnachrichten bei den verschiedenen Ereignissen zu senden sind, wenn man in den verschiedenen Zuständen arbeitet.
// Beachte: Muss neu geschrieben werden und bezieht sich nicht auf FH-, FO- und IR-Pakete
Im NC-Zustand:

– Wenn ein FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf R gesetzt ist Bormann (Herausgeber) [Seite 46] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
– Wenn ein FO- oder SO-Paket empfangen wird, oder wenn die Dekomprimierung eines FH-Pakets misslungen ist, sende eine STATIC-NACK, bei der der Modusparameter auf R gesetzt ist.

Im SC-Zustand:

– Wenn ein FO- oder FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf R gesetzt ist
– Wenn ein SO-Paket empfangen wird, sende eine NACK, bei der der Modusparameter auf R gesetzt ist
– Wenn die Dekomprimierung eines FO- oder FH-Pakets misslungen ist, sende eine STATIC-NACK, bei der der Modusparameter auf R gesetzt ist

Im FC-Zustand:

– Wenn ein FO- oder FH-Paket korrekt dekomprimiert wird, sende eine ACK, bei der der Modusparameter auf R gesetzt ist
– Wenn ein aktualisierendes SO-Paket korrekt dekomprimiert wird, sende periodisch eine ACK, bei der der Modusparameter auf R gesetzt ist.
– Wenn die Dekomprimierung eines SO-, FO- oder FH-Pakets misslungen ist, sende eine NACK, bei der der Modusparameter auf R gesetzt ist.

5.6 Modusübergänge
Die Entscheidung, sich von einem Komprimierungsmodus zu einem anderen zu bewegen, wird durch den Dekomprimierer vorgenommen, und die möglichen Modusübergänge sind in der unten stehenden Figur gezeigt. Die nachfolgenden Kapitel beschreiben, wie die Übergänge durchgeführt werden, mit den Ausnahmen für die Komprimierungs- und Dekomprimierungsfunktionalität zwischen Übergängen.
5.6.1 Komprimierung und Dekomprimierung während Modusübergängen
Um korrekt zu arbeiten, müssen sowohl der Komprimierer als auch der Dekomprimierer eine Variable haben, in welchem Modus sie gemäß ihr arbeiten sollen. Nachfolgende Kapitel definieren exakt, wann der Wert dieses Modusvariablen zu ändern ist und somit der Modus des Betriebs zu ändern ist. Weiterhin gibt es, wenn die ROHC von einem Modus zu einem anderen übergeht, mehrere Fälle mit speziellen Regeln, was auf der Seite des Komprimierers und des Dekomprimierers während der Übergangsphase getan werden darf. Diese speziellen Regeln sind durch Ausnahmeparameter definiert, die verschiedene Ausnahmeregeln festsetzen, denen zu folgen ist. Die Übergangsbeschreibungen in den nachfolgenden Kapiteln beziehen sich auf diese Ausnahmeparameter und definieren, wann und auf welche Werte diese zu setzen sind. Alle sich auf den Modus beziehenden Parameter sind unten aufgelistet mit möglichen Werten, Erläuterungen und Regeln:
Parameter für die Seite des Komprimierers:
– C MODE
Mögliche Werte für den C_MODUS-Parameter sind (U)NIDIREKTIONAL, (O)PTIMISTISCH und (R)ZUVERLÄSSIG. Zu Beginn muss der Wert auf U gesetzt werden.
– C TRANS
Mögliche Werte für den C_TRANS-Parameter sind (P) PENDING (anstehend) und (D) DONE (getan). Anfangs muss der Wert auf D gesetzt werden. Wenn der Parameter auf P gesetzt wird, ist es notwendig, dass der Komprimierer nur Paketformate verwendet, die allen Modi gemeinsam sind, und es soll kein Übergang in den SO-Zustand erlaubt werden. Eine neue Anforderung für einen Modusübergang muss auch ignoriert werden, wenn ein schon initiierter Übergang anstehend ist.
Bormann (Herausgeber) [Seite 48]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Parameter für die Seite des Dekomprimierers:
– D MODE
Mögliche Werte für den D_MODE-Parameter sind (U)NIDIREKTIONAL, (O)PTIMISTISCH und (R)ZUVERLÄSSIG. Zu Beginn muss der Wert auf U gesetzt werden.
– D TRANS
Mögliche Werte für den D_TRANS-Parameter sind (I)NITIIERT, (P) Pending (anstehend) und (D) DONE (getan). Anfangs muss der Wert auf D gesetzt werden. Neue Modulübergänge sind nur erlaubt, wenn der Parameter auf D gesetzt wird. Wenn er auf I gesetzt ist, sollte der Dekomprimierer eine NACK oder eine ACK für alle empfangenen Pakete senden, was er stoppen kann, wenn der Parameter auf P oder D gesetzt wird.
5.6.2. Übergang vom unidirektionalen in den optimistischen Modus
Solange es einen verfügbaren Rückkopplungskanal gibt, kann der Dekomprimierer in jedem Moment entscheiden, einen Übergang vom unidirektionalen in den bidirektionalen optimistischen Modus zu initiieren. Alle Rückkopplungspakete können verwendet werden, wenn der Modusparameter auf O gesetzt ist, und der Dekomprimierer kann dann direkt beginnen, im optimistischen Modus zu arbeiten. Der Komprimierer geht vom unidirektionalen in den optimistischen Modus, sobald er irgend ein Rückkopplungspaket empfängt, bei dem der Modusparameter auf O gesetzt ist. Das Übergangsverfahren ist unten beschrieben:
Wenn das Rückkopplungspaket verloren geht, wird der Komprimierer weiter im unidirektionalen Modus arbeiten mit periodischen Wiederauffrischungen, aber sobald der Dekomprimierer ein anderer Rückkopplungspaket sendet, wird auch der Komprimierer in den optimistischen Modus übergehen.
Bormann (Herausgeber) [Seite 49]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.6.3 Vom optimistischen in den zuverlässigen Modus
Ein Übergang vom optimistischen in den zuverlässigen Modus ist nur erlaubt, nachdem mindestens ein Paket korrekt dekomprimiert wurde, was bedeutet, dass der statische Teil des Kontexts errichtet ist. Entweder wird das ACK(R) oder NACK(R) Rückkopplungspaket verwendet, um den Übergang zu initiieren, wobei der Komprimierer während des Übergangs immer im FO-Zustand laufen muss. Das Übergangsverfahren ist unten beschrieben:
Solange wie der Dekomprimierer nicht ein FO-Paket, bei dem der Modusübergangsparameter auf R gesetzt ist, empfangen hat, muss er im optimistischen Modus bleiben. Der Komprimierer muss im FO-Zustand bleiben, bis er eine ACK für ein FO-Paket empfangen hat, das mit dem Modusübergangsparameter, der auf R gesetzt ist, gesendet wird (angezeigt durch die Sequenznummer).
5.6.4 Vom unidirektionalen in den zuverlässigen Modus
Da der Übergang vom unidirektionalen in den optimistischen Modus kein Handshake erfordert, ist es möglich, direkt vom unidirektionalen in den zuverlässigen Modus überzugehen, wobei man demselben obigen Übergangsverfahren 5.6.3 folgt.
5.6.5. Vom zuverlässigen zum optimistischen Modus
Entweder das ACK(0) oder NACK(0) Rückkopplungspaket wird verwendet, um den Übergang vom zuverlässigen in den optimistischen Modus zu initiieren, und der Komprimierer muss während des Übergangs immer im FO-Zustand laufen. Das Übergangsverfahren ist unten beschrieben:
Bormann (Herausgeber) [Seite 50]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Solange wie der Dekomprimierer nicht ein FO-Paket, bei dem der Modusübergangsparameter auf O gesetzt ist, empfangen hat, muss er im zuverlässigen Modus bleiben. Der Komprimierer muss im FO-Zustand bleiben, bis er eine ACK für ein FO-Paket empfangen hat, das mit dem Modusübergangsparameter, der auf O gesetzt ist, gesendet wird (angezeigt durch die Sequenznummer).
5.6.6. Übergang in den unidirektionalen Modus
Es ist möglich, einen Übergang zurück zum unidirektionalen Modus zu erzwingen, wenn der Dekomprimierer dies wünscht. Unabhängig von welchem Modus er startet, muss ein Dreiwege-Handshake ausgeführt werden, um einen korrekten Übergang auf der Seite des Komprimierers zu gewährleisten. Das Übergangsverfahren ist unten beschrieben.

Bormann (Herausgeber) [Seite 51]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Der Dekomprimierer muss weiter eine Rückkopplung senden, bis er weiß, dass der Komprimierer mit dem Übergang fertig ist.
Bormann (Herausgeber) [Seite 52]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000 5.7 Paketformate 5.7.1 Pakettyp 0: UO-0, R-0, R-0-CRC

SN LSB:: Niederwertigste Bits der RTP SN (Beachte, dass bei der R-0-CRC die SN LSB eine Bytegrenze überspannen)
CRC:: 7-Bit CRC, berechnet gemäß Abschnitt 5.9.2.

SN LSB:: Niederwertigste Bits der RTP SN (siehe Abschnitt 4.5.1)
CRC:: 3-Bit CRC (siehe Abschnitt 5.9.2)

Der UO-0 Kopfabschnitt darf keinen Teil des Kontext aktualisieren, der nicht direkt zur RTP SN in Bezug steht.
5.7.2 Pakettyp 1 (R-Modus): R-1, R-1-TS, R-1-ID
Dieser Pakettyp wird im R-Modus verwendet, wenn die RTP SN des zu komprimierenden Kopfabschnitts sich so stark vom Kontext unterscheidet, dass die LSB des Pakettyps 0 zu klein sind, oder wenn die Funktionen von der RTP SN zum RTP Zeitstempel oder IP-ID sich ändern und an den Dekomprimierer übermittelt werden müssen. Es ist auch möglich, Werte für andere Felder durch die Verwendung einer Erweiterung zu geben.
Bormann (Herausgeber) [Seite 53]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

SN LSB:: Niederwertigste Bits der RTP SN, siehe Abschnitt 4.5.1
M:: RTP Markierungsbit, absoluter Wert.
X:: X = 0 zeigt an, dass keine Erweiterung vorhanden ist. X = 1 zeigt an, dass eine Erweiterung vorhanden ist.
T:: T = 0 zeigt Format R-1-ID an, T = 1 zeigt Format R-1-TS an.
TS LSB:: Niederwertigste Bits des skalierten RTP TS, siehe Abschnitt 5.x.x. Bormann (Herausgeber) [Seite 54] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
IP-ID LSB:: Niederwertigste Bits des IP-ID Versatzes der SN, siehe Abschnitt 5.x.x.

5.7.3 Pakettyp 1 (UO-Modi): UO-1, UO-1-ID, UO-1-TS
Dieser Pakettyp wird im U-Modus und O-Modus verwendet, wenn sich die RTP SN des zu komprimierenden Kopfabschnitts so stark vom Kontext unterscheidet, dass die RTP LSB des Pakettyps 0 zu klein sind, oder wenn die Funktionen von der RTP SN zum RTP Zeitstempel oder IP-ID sich ändern und an den Dekomprimierer weitergegeben werden müssen. Es ist auch möglich, nicht aktualisierende Werte für andere Felder unter Verwendung einer Erweiterung anzugeben.

SN LSB:: Niederwertigste Bits der RTP SN, siehe Abschnitt 4.5.1. Bormann (Herausgeber) [Seite 55] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
M:: RTP Markierungsbit, absoluter Wert.
TS LSB:: Niederwertigste Bits des skalierten RTP TS, siehe Abschnitt 5.x.x.
CRC:: 3-Bit CRC (siehe Abschnitt 5.9.2)
IP-ID LSB:: Niederwertigste Bits des IP-ID Versatzes der SN, siehe Abschnitt 5.x.x.
X:: X = 0 zeigt an, dass keine Erweiterung vorhanden ist. X = 1 zeigt an, dass eine Erweiterung vorhanden ist.
T:: T = 0 zeigt Format UO-1-ID an, T = 1 zeigt Format UO-1-TS an.

5.7.4. Pakettyp 2: UOR-2
Dieser Pakettyp wird in allen Betriebsarten verwendet, wenn die Änderungen, die übertragen werden müssen, oder die RTP SN nicht in die früheren Formate passen. Das UOR-2 Format aktualisiert den Kontext immer (oder frischt ihn wieder auf).
Bormann (Herausgeber) [Seite 56]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

TS LSB:: Niederwertigste Bits des skalierten RTP TS, siehe Abschnitt 5.x.x.
msb:: Ein-Bit-Erweiterung des TS LSB Feldes, so dass die gesamte Größe der LSB des skalierten TS 6 Bits beträgt. Das sind die höchstwertigsten Bits.
M:: RTP Markierungsbit, absoluter Wert.
SN LSB:: Niederwertigste Bits der RTP SN, siehe Abschnitt 4.5.1.
IP-ID LSB:: Niederwertigste Bits des IP-ID Versatzes der SN, siehe Abschnitt 5.x.x.
X:: X = 0 zeigt an, dass keine Erweiterung vorhanden ist. X = 1 zeigt an, dass eine Erweiterung vorhanden ist.
CRC:: 7-Bit CRC (siehe Abschnitt 5.9.2)
T:: T = 0 zeigt Format UOR-2-ID an, T = 1 zeigt Format UOR-2-TS an.

5.7.5 Formate der Erweiterung
Felder in Erweiterungen werden mit dem entsprechenden Feld in der Basis des komprimierten Kopfabschnitts verkettet, wenn es welche gibt. Bits in einer Erweiterung sind höherwertiger als Bits in der Basis des komprimierten Kopfabschnitts.
Bormann (Herausgeber) [Seite 57]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Das TS LSB Feld ist in allen Erweiterungen skaliert, da es den Basiskopfabschnitt darstellt, mit der optionalen Ausnahme bei der Verwendung einer Erweiterung 3, bei der das Tsc-Flag anzeigen kann, dass das RTP TS LSB Feld nicht skaliert ist. Wenn eine Erweiterung ein TS-Schritt Feld trägt, wird der Wert dieses Feldes verwendet, wenn man das TS LSB Feld skaliert.
In den folgenden drei Erweiterungen hängt die Interpretation der Felder davon ab, ob es ein T-Bit im komprimierten Basiskopfabschnitt gibt, und wenn dem so ist, vom Wert dieses Feldes. Wenn es kein T-Bit gibt, so bedeuten T LSB und –T LSB beide TS LSB. Wenn es ein T-Bit gibt:
T = 1 zeigt an, dass T TS ist, und
–T IP-ID ist.
T = 0 zeigt an, dass T IP-ID ist, und
–T TS ist.
Erweiterung 0:
Erweiterung 1:
Erweiterung 2:
Die Erweiterung 3 ist eine kompliziertere Erweiterung, die Werte für andere Felder als RTP SN, RTP TS und IP-ID geben kann. Drei optionale Flag-Oktette zeigen Änderungen an dem oder den IP-Kopfabschnitten beziehungsweise am RTP-Kopfabschnitt an.
Bormann (Herausgeber) [Seite 58]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000 Erweiterung 3:

[Anmerkung von Mike D: Dieses Format kann mit zwei IP-Kopfabschnitten umgehen, was das ist, was wir vom Mobil-IP erwarten können. Noch mehr ist übertrieben, denke ich.]
Bormann (Herausgeber) [Seite 59]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
5.7.6 Rückkopplungspakete: RÜCKKOPPLUNG-3 und RÜCKKOPPLUNG-4
Wenn die Umlaufszeit zwischen dem Komprimierer und dem Dekomprimierer groß ist, können mehrere Pakete unterwegs sein. Somit können mehrere Pakete durch den Dekomprimierer empfangen werden, bevor der Komprimierer auf ein Rückkopplungspaket reagieren kann.
Der Dekomprimierer sollte keine Rückkopplungspakete für jede erfolgreiche Dekomprimierung, nicht erfolgreiche Dekomprimierung oder Paket, das in einem zurückgewiesenen Paketstrom empfangen wurde, senden. Stattdessen sollte der Komprimierer die Rate, mit der die Rückkopplungspakete gesendet werden, begrenzen.
Das Folgende sind die Formate der Rückkopplungspakete. Ihnen muss eine CID vorhergehen, die identifiziert, zu welchem Kontext sie gehören.
Es sei vorweggenommen, dass Rückkopplungspakete verschachtelt mit Nicht-Rückkopplungspaketen in einem Kanal gesendet werden können, der vom Dekomprimierer zum Komprimierer verläuft. In diesem Fall geht den unten stehenden Formaten eine CID vorher, mit der Größe, die für diesen Kanal ausgehandelt wurde. Wenn die CIDs dieses Kanals kleiner als die CIDs sind, die in den Rückkopplungspaketen benötigt werden, müssen zusätzliche Bytes der CID in den Rückkopplungsformaten hinzugefügt werden. Wie viele Byte hinzuzufügen sind, ist zur Zeit des Kanalaufbaus bekannt und nicht ausdrücklich angezeigt. Wenn die CIDs des Rückkopplungskanals größer als solche des Vorwärtskanals sind, wird der numerische Wert der CID verwendet, um den Kontext zu identifizieren. RÜCKKOPPLUNG-3

Typ: 0 = Reserviert

1 = ACK

2 = NACK

3 = STATIC-NACK

Modus 0 = Reserviert

1 = unidirektional

2 = bidirektional, optimistisch

3 = bidirektional, zuverlässig

RTP SN LSB:: LSB der RTP Sequenznummer von
ACK:: dem erfolgreich dekomprimierten Kopfabschnitt, der bewirkt, dass das Rückkopplungspaket ausgegeben wird, Bormann (Herausgeber) [Seite 60] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
NACK,STATIC-NACK:: der letzte erfolgreich dekomprimierte Kopfabschnitt (vom Kontext), wenn irgend einer verfügbar, sonst null.

Ein oder mehrere zusätzliche CID Oktett(e): Zusätzlich Oktette der CID, wenn es eine Fehlanpassung zwischen den CID-Räumen des Vorwärtskanals und des Rückkopplungskanals gibt. RÜCKKOPPLUNG-4-ZURÜCKGEWIESEN

Typ:: 4
CRC:: CRC berechnet über das gesamte RÜCKKOPPLUNG-4-ZURÜCKGEWIESEN Paket, einschließlich der CID, unter Verwendung des Polynoms für 7 Bit CRCs im Abschnitt 5.9.2. Für die Zwecke der CRC-Berechnung muss das CRC-Feld auf null gesetzt werden. Wenn der Komprimierer ein RÜCKKOPPLUNG-4-ZURÜCKGEWIESEN Paket empfängt, muss er den CRC prüfen, und prüfen, dass die zu null gemachten Felder des RÜCKKOPPLUNG-4-ZURÜCKGEWIESEN Pakets tatsächlich null sind. Wenn diese Prüfung misslingt, muss das Paket verworfen werden und keine weitere Aktion stattfinden.

Ein oder mehrere zusätzliche CID Oktette: Zusätzliche Oktette der CID, wenn es eine Fehlanpassung zwischen den CID-Räumen des Vorwärtskanals und des Rückkopplungskanals gibt. RÜCKKOPPLUNG-4

Typ: 0, 5–7 = Reserviert

1 = ACK

2 = NACK

3 = STATIC-NACK

Bormann (Herausgeber) [Seite 61]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

Modus 0 = Reserviert

1 = unidirektional

2 = bidirektional, optimistisch

3 = bidirektional, zuverlässig

RTP SN LSB (msb):: Höchstwertigste 6 Bits der 14 Bit RTP SN LSB.
RTP SN LSB (lsb):: Niederwertigste 6 Bits der 14 Bit RTP SN LSB.

5.7.7 IR und IR-DYN Pakete
Die Unterkopfabschnitte, die komprimierbar sind, sind in einen statischen Teil und einen dynamischen Teil aufgespaltet. Diese Teile kann man in den Abschnitten 5.7.6.3-* finden.
Die Struktur einer Kette von Unterkopfabschnitten wird durch jeden Kopfabschnitt, der ein Feld "Nächster Kopfabschnitt" oder "Protokoll" aufweist, bestimmt. Dieses Feld identifiziert den Typ des folgenden Kopfabschnitts. Jeder statische Teil unten enthält dieses Feld und erlaubt ein Analysieren der statischen Kette.
5.7.7.1 Grundstruktur des IR-Pakets
Dieser Pakettyp überträgt den statischen Teil des Kontexts, das ist der Wert der konstanten SN-Funktionen. Er kann optional auch die dynamischen Teile des Kontext übertragen, das sind die Parameter der nicht konstanten SN-Funktionen. Er kann auch optional die Nutzdaten eines ursprünglichen Pakets, sofern vorhanden, übertragen.
Bormann (Herausgeber) [Seite 62]
INTERNET-ENTWURF Robuste Kapfabschnittskomprimierung
18. September 2000

D:: D = 1 zeigt an, dass die dynamische Kette vorhanden ist.
P:: P = 1 zeigt an, dass Nutzdaten vorhanden sind (könnte gefolgert werden aus der statischen Kette plus der Rahmenlänge).
Profil:: Zeigt Transport/Anwendung dieses Stroms an.
CRC:: 8-Bit Prüfsumme, die den gesamten IR-Kopfabschnitt abdeckt, einschließlich CID, ausschließlich Nutzdaten, berechnet gemäß dem Kapitel 5.9.x.
Statische Kette:: Eine Kette statischer Unterkopfabschnittsinformation
Dynamische Kette:: Eine Kette dynamischer Unterkopfabschnittsinformation. Welche dynamische Information vorhanden ist, kann aus der statischen Kette abgeleitet werden.
Nutzdaten:: Nutzdaten des entsprechenden ursprünglichen Pakets, sofern vorhanden.

5.7.7.2 Basisstruktur des IR-DYN Pakets
Dieser Pakettyp übermittelt den dynamischen Teil des Kontexts, das sind die Parameter der nicht konstanten SN-Funktionen.
Bormann (Herausgeber) [Seite 61]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

res:: wird auf null gesetzt beim Senden, ignoriert beim Empfangen.
P:: P = 1 zeigt an, dass Nutzdaten vorhanden sind.
Profil:: Zeigt Transport/Anwendung dieses Datenstroms an
CRC:: 8-Bit Prüfsumme, die den gesamten IR-DYN Kopfabschnitt abdeckt, einschließlich CID, ausschließlich Nutzdaten.
Dynamische Kette:: eine Kette dynamischer Unterkopfabschnittsinformation. Welche dynamische Information vorhanden ist, wird aus der statischen Kette des Kontext abgeleitet.
Nutzdaten:: Nutzdaten des entsprechenden ursprünglichen Pakets, sofern welche vorhanden sind.

5.7.7.3 Initialisierung des IPv6 Kopfabschnitts [IPv6] Statischer Teil:
Dynamischer Teil:
Eliminiert:

Nutzdatenlänge Bormann (Herausgeber) [Seite 64] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000 5.7.7.4 Initialisierung des IPv4 Kopfabschnitts [IPv4, Abschnitt 3.1] Statischer Teil Version, Flags, Lebensdauer, Protokoll, Quellenadresse, Zieladresse

Dynamischer Teil: Typ des Dienstes, Identifikation

Eliminiert:

IHL	(muss 5 sein)
Gesamtlänge	(abgeleitet in dekomprimierten Paketen)
MF-Flag	(Mehrere-Fragmente-Flag, muss 0 sein)
Fragment-Versatz	(muss 0 sein)
Kopfabschnittprüfsumme	(abgeleitet in dekompr. Paketen)
Optionen, Auffüllen	(muss nicht vorhanden sein)

5.7.7.5 Initialisierung des UDP-Kopfabschnitts [RFC-768] Statischer Teil:

Bormann (Herausgeber) [Seite 65] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

Dynamischer Teil:
Eliminiert:

Länge

Das Längenfeld des UDP-Kopfabschnitts muss zu dem oder den Längenfeldern der vorhergehenden Unterkopfabschnitte passen, das heißt, es darf kein Auffüllen mit Nullen nach den UDP-Nutzdaten, die durch die IP-Länge abgedeckt werden, geben. 5.7.7.6. Initialisierung des RTP Kopfabschnitts [RTP] Statischer Teil: P, X, CC, PT, SSRC, CSRC Identifikatoren
Dynamischer Teil: M, Sequenznummer, Zeitstempel, Zeitstempel-Delta
Bormann (Herausgeber) [Seite 66]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Eliminiert:

Nichts

5.7.7.7. Kopfabschnitt mit minimaler Einkapselung (Minimal Encapsulation header [RFC-2004, Abschnitt 3.1] Statischer Teil: Gesamter Kopfabschnitt
Dynamischer Teil:

Leer.

Eliminiert:

Nichts. Bormann (Herausgeber) [Seite 67] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

5.8 Auf Listen basierende Komprimierung
In zwei Fällen kann Information vom zu komprimierenden Paket als eine geordnete Liste beschrieben werden, die größtenteils zwischen zwei Paketen konstant ist, aber bei der Hinzufügungen und Löschungen gelegentlich im Verlauf des Paketdatenstrom gemacht werden. Dieser Abschnitt beschreibt das Komprimierungsschema für diese Information, genannt "auf Listen basierende Komprimierung". Die zwei Fälle sind: CSRC-Listen in RTP Paketen, und Erweiterungskopfabschnittketten in IP-Paketen.
[[Anmerkung des Herausgebers: Dieser Abschnitt befindet sich noch unter aktiver Diskussion in der Mailing-Liste. Es wird angenommen, dass eine etwas vereinfachte Version bald erscheint.]]
5.8.1 CSRC-Komprimierung
Die Beitragende Quellenliste (Contributing Source List, CSRC) in einem RTP Kopfabschnitt enthält die Synchronisationsquellenidentifikatoren (Synchronization Source identifiers, SSRC) der zu den Nutzdaten beitragenden Quellen im aktuellen Paket.
Eine CSRC-Liste enthält maximal 15 Identifikatoren durch die Größe von 4 Bit des CSRC Zählfeldes (CC) im RTP-Kopfabschnitt. Jeder 32-Bit Identifikator wird zufällig durch die ursprüngliche Synchronisationsquelle gewählt, so dass er innerhalb einer RTP-Sitzung global eindeutig ist.
Das hier eingeführte Komprimierungsschema wird die oben erwähnten Tatsachen verwenden. Um die Transparenz aufrecht zu halten, wird die Reihenfolge der Identifikatoren während der Komprimierung bewahrt. Mit anderen Worten, die SCRC-Liste wird wirklich als eine Liste und nicht als ein Satz komprimiert.
5.8.1.1 Transformationsklassifikation für CSRC-Liste
Eine gegebene CSRC-Liste (curr_list) kann klassifiziert werden, wie sie zu einer der folgenden Transformationsfälle gehört, wenn sie mit einer Referenz-CSRC-Liste (ref_list) verglichen wird.

– Transformation Fall A: curr_list kann aus der ref_list einfach durch das Addieren einiger CSRCs abgeleitet werden; die relativen Positionen der CSRCs, die der curr_list und der ref_list gemeinsam sind, sind dieselben.
– Transformation Fall B: curr_list kann aus ref_list einfach durch das Löschen einiger CSRCs abgeleitet werden; die relativen Positionen der CSRCs, die der curr_list und der ref_list gemeinsam sind, sind dieselben.
– Transformation Fall C: Alle anderen Transformationsfälle, die nicht durch die Transformationsfälle A und B abgedeckt werden.

5.8.1.2. Kodierschemata
Um die vorher erwähnten 3 Transformationsfälle anzusprechen, werden vier Kodierschemata verwendet. Jedes Schema spricht einen oder mehrere der oben erwähnten Transformationsfälle an. Die vier Kodierschemata und die Transformationsfälle, die sie ansprechen, sind in der folgenden Tabelle aufgelistet.
Bormann (Herausgeber) [Seite 68]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

– Im Schema des ausschließlichen Einschubs werden im Vergleich zur CSRC-Liste in der ref_list die neu hinzugefügten CSRCs in der curr_list zusammen mit den Positionen der CSRCs in der ref_list gesendet, bevor die neuen CSRCs eingeschoben werden.
– Im Schema des ausschließlichen Entfernes werden die Positionen der CSRCs, die sich in der ref_list aber nicht in der curr_list befinden, gesendet.
– Im allgemeinen Schema wird für eine gegebene CSRC in der curr_list diese nur mit einem Positionsfeld gesendet, wenn die CSRC sich auch in der ref_list befindet, oder sie wird unkomprimiert gesendet.

Alle drei vorher erwähnten Schemata erzeugen ein komprimiertes Format der CSRC-Liste. Die CSRC-Liste kann auch in einem nicht komprimierten Format gesendet werden.
5.8.1.3 Format der komprimierten CSRC-Liste
Das Format der komprimierten CSRC-Liste, die die vier Schemata verwendet, ist folgendermaßen. 5.8.1.3.1 Schema des ausschließlichen Einschubs 5.8.1.3.1.1 R-Modus

– ref_id – die LSB der RTP Sequenznummer der ref_list Bormann (Herausgeber) [Seite 69] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000 6 Bit: "0" + 5-Bit LSB der RTP Sequenznummer 14 Bit: "1" + 13 Bit LSB der RTP Sequenznummer
– Einschubbitmaske: Die Bitmaske, die die Position der folgenden in die ref_list einzuschiebenden CSRCs anzeigt, um die curr_list zu rekonstruieren.

Die Länge der Einschubbitmaske kann 8 Bits oder 16 Bits betragen.
8 Bits: "0" + 7-Bit Einschubbitmaske
16 Bits: "1" + 15-Bit Einschubbitmaske
Um die Einschubbitmaske und die folgende eingeschobene CSRC-Liste zu konstruieren, werden die folgenden Schritte unternommen:

– Eine Liste von '0' und eine leere eingeschobene CSRC-Liste werden als Startpunkt erzeugt. Die Anzahl der '0's in der '0' Liste ist gleich der Anzahl der CSRCs in der ref_list. Die i-te '0' in der '0'-Liste entspricht der i-ten CSRC in der ref_list.
– Vergleichen der curr_list mit der ref_list, wenn ein neues CSRC zwischen dem i-ten Objekt und dem (i + 1)-ten Objekt in die ref_list eingeschoben wird, so wird eine '1' zwischen die i-te '0' und (i + 1)-te '0' in der ursprünglichen '0' Liste eingeschoben. Das neue CSRC sollte zum Ende der eingeschobenen CSRC-Liste addiert werden. Dieses Verfahren wird wiederholt, bis alle die m neuen CSRCs verarbeitet wurden. Wenn die Länge der neuen Einschubbitmaske weniger als 7 Bits oder 15 Bits beträgt, sollte eine zusätzliche '0' am Ende addiert werden, bis sie 7 Bits oder 15 Bits erreicht.

Wenn der Dekomprimierer die Einschubbitmaske empfängt, so führt er eine Abtastung von links nach rechts durch. Wenn eine '0' beobachtet wird, so kopiert der Dekomprimierer die entsprechende CSRC in der ref_list in die curr_list; wenn eine '1' beobachtet wird, so addiert der Dekomprimierer die entsprechende CSRC in die curr_list.

– CSRC i (i = 1 ... m): die einzuschiebenden CSRCs; man nimmt an, dass die Anzahl der einzuschiebenden CSRCs m ist.

– res.: reserviert Bormann (Herausgeber) [Seite 70) INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
– Gen_id: wird verwendet, um einen Satz von Paketen zu identifizieren, die zur selben Generation gehören
– ref_id: die Gen_id, die in der ref_list befördert wird
– Einschubbitmaske und CSRC i: dieselben wie sie für den R-Modus definiert wurden

– ref_id: dieselbe wie im Abschnitt 3.1.1 definiert.
– Entfernungsbitmaske: Die Bitmaske zeigt die CSRC in der ref_list an, die zu entfernen ist, um die curr_list zu rekonstruieren. Eine '1' im i-ten Bit in der Entfernungsbitmaske bedeutet, dass die i-te CSRC in der ref_list nicht in der curr_list ist, während eine '0' bedeutet, dass sie noch in der curr_list ist.

Die Länge der Einschubbitmaske kann 8 Bits oder 16 Bits betragen.
8 Bits: "0" + 7-Bit Einschubbitmaske
16 Bits: "1" + 15-Bit Einschubbitmaske
Welches Format zu verwenden ist, hängt von der Anzahl der CSRCs in der ref_list ab. Wenn sie weniger als 8 beträgt, dann kann die 8-Bit Entfernungsbitmaske verwendet werden; ansonsten ist das 16 Bit Format erforderlich. 5.8.1.3.2.2 UO-Modus

– Gen_id, res. und ref_id: dieselben wie im Abschnitt 3.1.2. definiert
– Entfernungsbitmaske: dieselbe wie für den R-Modus definiert Bormann (Herausgeber) [Seite 71] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

– ref_id: dieselbe wie im Abschnitt 3.1.1 definiert.
– gzähler: die Nummer des folgendenden g_CSRC-Feldes; die Länge beträgt 4 Bits.
– g_CSRC i (i = 1 ... m): entspricht der i-ten CSRC in der curr_list. Die Reihenfolge der g CSRC stellt die Reihenfolge der CSRCs in der curr_list dar. Zwei Typen von g_CSRC werden definiert.
– g_CSRC Typ 0 wird verwendet, um eine CSRC zu komprimieren, die sich sowohl in der ref_list als auch in der curr_list befindet.
– g_CSRC Typ 1 wird verwendet, um eine CSRC zu befördern, die sich in der curr_list aber nicht in der ref_list befindet.

Das Format von g_CSRC ist folgendermaßen definiert.

– pos: Die Position einer CSRC in der ref_list; die Länge hat eine obere Grenze (log2(k)), wobei k die Nummer der CSRC in der ref_list ist. Da der Wert von k sowohl dem Komprimierer als auch dem Dekomprimierer bekannt ist, muss die Länge des Positionsfeldes nicht in der komprimierten Liste befördert werden.

– Auffüllen: Füllbits können notwendig sein, um die Byteausrichtung aufrecht zu halten Bormann (Herausgeber) [Seite 72] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

– Gen_id und ref_id: dieselbe wie im Abschnitt 3.2.1.2 definiert.
– gzähler, g_CSRC und Auffüllen: dieselben wie für den R-Modus definiert.

– resv: reserviert
– G: zeigt die Anwesenheit des gen_id Feldes
– Gen_id: dieselbe wie in Abschnitt 3.1.2 definiert.
– im R-Modus ist gen_id nicht vorhanden.
– Während des Übergangs von irgend einem Modus in der U-Modus oder O-Modus sollte gen_id nicht gesendet werden. Die Liste ohne gen_id sollte nicht als eine Referenz verwendet werden, um eine CSRC-Liste zu komprimieren und zu dekomprimieren.
– in UO-Modi ist gen_id vorhanden, wenn es als eine Referenz verwendet werden kann, um die nachfolgende CSRC-Liste zu komprimieren oder zu dekomprimieren.
– czähler: Die Anzahl der CSRCs in der CSRC-Liste
– CSRC i (i = 1 ... m): die ursprüngliche CSRC-Liste in der curr_list

5.8.2 Kopfabschnittkomprimierung für Kopfabschnitte mit IPv6 Erweiterung
Die Kopfabschnitt mit IPv6 Erweiterung werden als eine Liste von Objekten kodiert. Jedes Objekt ist einer der Kopfabschnitte mit Erweiterung. Die Länge jedes Kopfabschnitts mit Erweiterung kann sich gegenseitig unterscheiden. Wenn mehr als ein Kopfabschnitt mit Erweiterung in demselben Paket verwendet wird, wird die Reihenfolge dieser Kopfabschnitte mit Erweiterung in der RFC 2460 empfohlen, aber nicht bindend. Somit kann, obwohl es unwahrscheinlich ist, dass es vorkommt, die Reihenfolge der Kopfabschnitte mit Erweiterung während derselben Sitzung variieren. Zusätzlich können ein oder mehrere Kopfabschnitte mit Erweiterung während der Sitzung hinzugefügt oder entfernt werden, und der Inhalt solcher Kopfabschnitte mit Erweiterung kann sich ändern. Somit werden die Kopfabschnitte mit IPv6 Erweiterung als eine Liste von Objekten klassifiziert und der Objektlistenkomprimierungsmechanismus kann angewandt werden.
Bormann (Herausgeber) [Seite 73]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Die Komprimierung der Kopfabschnitte mit der IPv6 Erweiterung auf dem Listenpegel ist ähnlich der der CSRC-Einträge (Abschnitt 5.8.1). Der komprimierte Wert der Liste der Kopfabschnitte mit der Erweiterung wird als eine komprimierte Liste des Kopfabschnitts mit der Erweiterung bezeichnet. Die Komprimierung der Kopfabschnitte mit der IPv6 Erweiterung auf Objektebene, das ist das Komprimierungsschema, das für jeden Typ eines Kopfabschnitts mit Erweiterung verwendet wird, wird in diesem Unterabschnitt definiert. Der Referenzkopfabschnitt mit Erweiterung, der verwendet wird, um einen gegebenen Kopfabschnitt mit Erweiterung zu komprimieren, ist der Kopfabschnitt mit Erweiterung in der Referenzliste, der denselben Typ aufweist. Der komprimierte Wert des Kopfabschnitts mit Erweiterung wird als ein komprimierter Kopfabschnitt mit Erweiterung bezeichnet.
5.8.2.1. Terminologie

– Liste der Kopfabschnitte mit Erweiterung: die Liste der Kopfabschnitte mit IPv6 Erweiterung
– komprimierter Kopfabschnitt mit Erweiterung: der komprimierte Wert eines Kopfabschnitts mit IPv6 Erweiterung
– Liste des komprimierten Kopfabschnitts mit Erweiterung: die Liste der komprimierten Kopfabschnitte mit Erweiterung
– Liste der Referenzkopfabschnitte mit Erweiterung: die Liste der Kopfabschnitte mit Erweiterung, die als eine Referenz verwendet wird, um eine Liste von Kopfabschnitten mit Erweiterung zu komprimieren
– Referenzkopfabschnitt mit Erweiterung: ein Kopfabschnitt mit Erweiterung in der Referenzliste, der denselben Typ hat und als eine Referenz verwendet wird, um einen gegebenen Kopfabschnitt mit Erweiterung zu komprimieren

5.8.2.2. Transformationsklassifikation und Kodierschemata
5.8.2.2.1 Transformationsklassifikation
Eine gegebene Liste von Kopfabschnitten mit Erweiterung (curr_list) kann klassifiziert werden als zugehörig zu einer der folgenden Transformationsfälle, wenn sie mit einer Liste von Referenzkopfabschnitten mit Erweiterung (ref_list) verglichen wird.

– Transformation Fall A: curr_list kann aus der ref_list einfach durch das Addieren (Einschieben) einiger Kopfabschnitte mit Erweiterung abgeleitet werden; die relativen Positionen der Kopfabschnitte mit Erweiterung, die der curr_list und der ref_list gemeinsam sind, sind dieselben.
– Transformation Fall B: curr_list kann aus ref_list einfach durch das Löschen einiger Kopfabschnitte mit Erweiterung abgeleitet werden; die relativen Positionen der Kopfabschnitte mit Erweiterung, die der curr_list und der ref_list gemeinsam sind, sind dieselben. Bormann (Herausgeber) [Seite 74] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
– Transformation Fall C: curr_list kann aus ref_list abgeleitet werden einfach durch das Modifizieren des Inhalts einiger Kopfabschnitte mit Erweiterung; die relativen Positionen der Kopfabschnitte mit Erweiterung bleiben dieselben.
– Transformation Fall D: Alle anderen Transformationsfälle, die nicht durch die Transformationsfälle A und B abgedeckt werden.

5.8.2.2.2 Kodierschemata
Um die vorher erwähnten 4 Transformationsfälle anzusprechen, werden vier Kodierschemata verwendet. Jedes Schema spricht einen oder mehrere der oben erwähnten Transformationsfälle an. Die vier Kodierschemata und die Transformationsfälle, die sie ansprechen, sind in der folgenden Tabelle aufgelistet.

– Im Schema des ausschließlichen Einschubs werden im Vergleich zur ref_list der nicht komprimierte Wert der neu hinzugefügten Kopfabschnitte mit Erweiterung in der curr_list zusammen mit den Positionen der Kopfabschnitte mit Erweiterung in der ref_list gesendet, bevor die neuen Kopfabschnitte mit Erweiterung eingeschoben werden.
– Im Schema des ausschließlichen Entfernes werden die Positionen der Kopfabschnitte mit Erweiterung, die sich in der ref_list aber nicht in der curr_list befinden, gesendet.
– Im Schema der ausschließlichen Änderung werden die Positionen der Kopfabschnitte mit Erweiterung, deren Inhalt geändert wird, als auch ihre nicht komprimierten oder komprimierten Werte gesendet. (Beachte, dass im aktuellen Zustand nur ein nicht komprimierter Kopfabschnitt mit Erweiterung verwendet wird.)

Die drei vorher erwähnten Schemata erzeugen ein komprimiertes Format der Liste der Kopfabschnitte mit Erweiterung. Die curr_list kann auch in einem nicht komprimierten Format gesendet werden.
5.8.2.2.3 Spezielle Handhabung
5.8.2.2.3.1 Spezielle Handhabung von AH

Bormann (Herausgeber) [Seite 75] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

Das Sequenznummernfeld im AH enthält einen monoton steigenden Zählerwert für eine Sicherheitsverbindung (security association). Wenn man somit die curr_list mit der ref_list vergleicht, so wird, wenn die Sequenznummer in AH sich ändert und das SPI-Feld sich nicht ändert, AH nicht notwendigerweise als geändert klassifiziert.
Wenn die Sequenznummer im der AH linear zunimmt, wenn die RTP Sequenznummer zunimmt, so muss sie nicht gesendet werden. Der Dekomprimierer wendet eine lineare Extrapolation an, um die Sequenznummer in AH zu rekonstruieren. Ansonsten sollte eine komprimierte Sequenznummer in das Komprimierungselementfeld der Kopfabschnitte mit IPv6 Erweiterung im Kopfabschnitt mit der PT 2 Erweiterung "11" eingeschlossen werden.
Das Authentikationsdatenfeld in der AH ändert sich von Paket zu Paket und sollte in jedem Paket gesendet werden. Wenn der nicht komprimierte AH gesendet wird, so wird das Authentifikationsdatenfeld innerhalb des nicht komprimierten AH gesendet; ansonsten wird es nach den komprimieren IP/UDP/RTP und Kopfabschnitten mit IPv6 Erweiterung und vor den Nutzdaten gesendet.
5.8.2.2.3.2 Kopfabschnitt mit eingebetteten Sicherheitsnutzdaten (Encapsulating Security Payload Header)
Wenn der Kopfabschnitt mit eingebetteten Sicherheitsnutzdaten (ESP) verwendet wird, werden die UDP- und RTP-Kopfabschnitte beide verschlüsselt und können nicht komprimiert werden. In diesem Fall muss ein speziell komprimiertes Paketformat in der ROHC definiert werden.
Im ESP sind die einzigen Felder, die komprimiert werden können, die SPI und die Sequenznummer.

– Wenn sich das SPI-Feld ändert, so wird der nicht komprimierte ESP gesendet.
– Wenn keine Änderung im SPI-Feld stattfindet, so wird der ESP als unverändert angesehen.

Die Sequenznummer in ESP weist dasselbe Verhalten wie dasselbe Feld in AH auf. Wenn es linear zunimmt, muss es nicht gesendet werden. Ansonsten sollte eine komprimierte Sequenznummer im Komprimierungselementfeld der Kopfabschnitte mit Erweiterung im Kopfabschnitt mit der PT 2 Erweiterung "11" gesendet werden.
5.8.2.2.3.3 Spezielle Handhabung des Feldes Nächster Kopfabschnitt
Das Feld "Nächster Kopfabschnitt" in einem Kopfabschnitt mit Erweiterung ändert sich immer wenn der Typ des direkt folgenden Kopfabschnitts sich ändert, beispielsweise wird ein neuer Kopfabschnitt mit Erweiterung nach ihm eingeschoben, der direkt nachfolgende Kopfabschnitt mit Erweiterung wird aus der Liste entfernt, oder die Reihenfolge mehrerer Kopfabschnitte mit Erweiterung wird geändert. Somit ist es nicht ungebräuchlich, dass für einen gegebenen Kopfabschnitt mit Erweiterung sich nur das Feld "Nächster Kopfabschnitt" ändert, aber die verbleibenden Felder sich nicht ändern. Somit muss das Feld "Nächster Kopfabschnitt" in jedem Kopfabschnitt mit Erweiterung auf eine spezielle Weise gehandhabt werden.
Bormann (Herausgeber) [Seite 76]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Wenn sich nur das Feld "Nächster Kopfabschnitt" ändert, sollte der Kopfabschnitt mit Erweiterung als nicht geändert betrachtet werden. Die spezielle Behandlung der Änderung des Feldes "Nächster Kopfabschnitt" ist folgendermaßen definiert.

– Im Fall, dass ein nachfolgender Kopfabschnitt mit Erweiterung aus der Liste entfernt wird, kann der neue Wert des Feldes "Nächster Kopfabschnitt" aus der Liste des Referenzkopfabschnitts mit Erweiterung erhalten werden. Man nehme beispielsweise an, dass die Liste des Referenzkopfabschnitts mit Erweiterung (ref_list) aus Kopfabschnitten mit Erweiterung A, B und C (ref_ext_hdr A, B, C) besteht und die aktuelle Liste des Kopfabschnitts mit Erweiterung (curr_list) nur aus den Kopfabschnitten mit Erweiterung A und C (curr_ext_hdr A, C) besteht. Die Reihenfolge und der Wert des Feldes "Nächster Kopfabschnitt" dieser Kopfabschnitte mit Erweiterung sind folgendermaßen.

Beim Vergleichen des curr_ext_hdr A in curr_list und des ref_ext_hdr A in ref_list wird der Wert des Feldes "Nächster Kopfabschnitt" durch die Entfernung des Kopfabschnitts B mit Erweiterung vom "Typ B" zum "Typ C" geändert.
Der neue Wert des Feldes "Nächster Kopfabschnitt" in curr_ext_hdr A, das ist "Typ C" muss nicht an den Dekomprimierer gesendet werden, da wenn der Dekomprimierer (durch das Beobachten der Kodierung auf Listenebene) erkennt, dass der direkt folgende Kopfabschnitt B mit Erweiterung aus der Liste entfernt wird, so findet er das Feld "Nächster Kopfabschnitt" in ref_ext_hdr B und verwendet es, um das Feld "Nächster Kopfabschnitt" in curr_ext_hdr A zu ersetzen.

– Im Falle, dass ein neuer Kopfabschnitt mit Erweiterung nach einem existierenden Kopfabschnitt mit Erweiterung eingeschoben wird, trägt das Feld "Nächster Kopfabschnitt" im neuen Kopfabschnitt mit Erweiterung den Typ seiner selbst statt des Typs des Kopfabschnitts mit Erweiterung, der folgt. Man nehme beispielsweise an, dass die Liste des Referenzkopfabschnitts mit Erweiterung (ref_list) aus Kopfabschnitten mit Erweiterung A, und C (ref_ext_hdr A, C) besteht, und die aktuelle Liste des Kopfabschnitts mit Erweiterung (curr_list) aus den Kopfabschnitten mit Erweiterung A, B und C (curr_ext_hdr A, B, C) besteht. Die Reihenfolge und der Wert des Feldes "Nächster Kopfabschnitt" dieser Kopfabschnitte mit Erweiterung sind folgendermaßen.

Beim Vergleichen der curr_list und der ref_list wird der Wert des Feldes "Nächster Kopfabschnitt" im Kopfabschnitt A mit Erweiterung vom "Typ C" zum "Typ D" geändert.
In der Liste des komprimierten Kopfabschnitts mit Erweiterung wird das unkomprimierte curr_ext_hdr B im nicht komprimierten Datenfeld im c_Objekt oder u_Objekt in Abhängigkeit vom verwendeten Listenkodierschema befördert. Statt des Beförderns des Typs des nächsten Kopfabschnitts (Typ C) im Feld "Nächster Kopfabschnitt" sollte der Typ von curr_ext_hdr B (Typ B) befördert werden. Wenn der Dekomprimierer (durch das Beobachten der Kodierung auf Listenebene) detektiert, dass eine neue Erweiterung nach curr_ext_hdr A eingeschoben wird, wird er das alte Feld "Nächster Kopfabschnitt" in ref_ext_hdr A durch den Typ des eingeschobenen Kopfabschnitts mit Erweiterung ersetzten, das ist der Typ B, das im Feld "Nächster Kopfabschnitt" im c_Objekt oder u_Objekt für den Kopfabschnitt B mit Erweiterung befördert wird. Zur selben Zeit ersetzt der Dekomprimierer auch das Feld "Nächster Kopfabschnitt" in curr_ext_hdr B durch den alten Wert des Feldes "Nächster Kopfabschnitt" in ref_ext_hdr A, das ist Typ C. 5.8.2.3 Paketformat 5.8.2.3.1 Format im Kopfabschnitt mit der Erweiterung "11"
Bormann (Herausgeber) [Seite 78]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000

– ASeq: Vorhandensein der komprimierten AH Sequenznummer
– ESeq: Vorhandensein der komprimierten ESP Sequenznummer
– CExt: Vorhandensein des komprimierten Kopfabschnitts mit IPv6 Erweiterung
– Formate der komprimierten AH Sequenznummer und der komprimierten ESP Sequenznummer: "0" + 7-Bit LSB "11" + 30-Bit LSB

– ref_id – die LSB der RTP Sequenznummer der ref_list 6 Bit: "0" + 5-Bit LSB 14 Bit: "1" + 13 Bit LSB
– u_ehdr i (i = 1 ... m): der nicht komprimierte Wert des neuen Kopfabschnitts mit Erweiterung in der curr_list; m ist die Anzahl der neuen Kopfabschnitte mit Erweiterung, die zu addieren sind.
– Einschubbitmaske: Die Bitmaske, die die Position der folgenden in die ref_list einzuschiebenden u_ehdrs anzeigt, um die curr_list zu rekonstruieren.

Die Länge der Einschubbitmaske beträgt 8-Bits.
Um die Einschubbitmaske und die folgende eingeschobene u_ehdr-Liste zu konstruieren, werden die folgenden Schritte unternommen:

– Eine Liste von '0' und eine leere eingeschobene u_ehdr-Liste werden als Startpunkt erzeugt. Die Anzahl der '0's in der '0' Liste ist gleich der Anzahl der Kopfabschnitte mit Erweiterung in der ref_list. Die i-te '0' in der '0'-Liste entspricht dem i-ten Kopfabschnitt mit Erweiterung in der ref_list.
– Vergleichen der curr_list mit der ref_list, wenn ein neuer Kopfabschnitt mit Erweiterung zwischen dem i-ten Objekt und dem (i + 1)-ten Objekt in die ref_list eingeschoben wird, so wird eine '1' zwischen die i-te '0' und (i + 1)-te '0' in der ursprünglichen '0' Liste eingeschoben. Der neue Kopfabschnitt mit Erweiterung sollte zum Ende der eingeschobenen CSRC-Liste addiert werden. Dieses Verfahren wird wiederholt, bis alle die m neuen Kopfabschnitte mit Erweiterung verarbeitet wurden. Wenn die Länge der neuen Einschubbitmaske weniger als 7 Bits oder 15 Bits beträgt, sollte eine zusätzliche '0' am Ende addiert werden, bis sie 7 Bits erreicht.

Wenn der Dekomprimierer die Einschubbitmaske empfängt, so führt er eine Abtastung von links nach rechts durch. Wenn eine '0' beobachtet wird, so kopiert der Dekomprimierer den entsprechenden Kopfabschnitt mit Erweiterung in der ref_list in die curr_list; wenn eine '1' beobachtet wird, so addiert der Dekomprimierer den entsprechenden u_ehdr in die curr_list. 3.2.1.2 UO-Modi

– resv: reserviert
– Gen_id: wird verwendet, um einen Satz von Paketen zu identifizieren, die zur selben Generation gehören
– ref_id: die Gen_id, die in der ref_list befördert wird
– Einschubbitmaske und u_ehdr i: dieselben wie sie für den R-Modus definiert wurden

– ref_id: dieselbe wie im Abschnitt 3.2.1.1 definiert.
– Entfernungsbitmaske: Die Bitmaske zeigt den Kopfabschnitt mit Erweiterung in der ref_list an, der zu entfernen ist, um die curr_list zu rekonstruieren. Eine '1' im i-ten Bit in der Entfernungsbitmaske bedeutet, dass der i-te Kopfabschnitt mit Erweiterung in der ref_list nicht in der curr_list ist, während eine '0' bedeutet, dass sie noch in der curr_list ist.

Die Länge der Einschubbitmaske kann 8 Bits betragen. 3.2.2.2 UO-Modi

– Gen_id, resv und ref_id: dieselben wie im Abschnitt 3.2,1.2. definiert
– Entfernungsbitmaske: dieselbe wie für den R-Modus definiert

– ref_id: dieselbe wie sie im Abschnitt 2.3.1.1 definiert ist
– Änderungsbitmaske: eine Bitmaske, die die Position des Kopfabschnitts mit Erweiterung, der geändert wird, anzeigt. Eine '1' im i-ten Bit in der Änderungsbitmaske bedeutet, dass der i-te Kopfabschnitt mit Erweiterung in der ref_list nicht derselbe ist wie die i-te Erweiterung in der curr_list, während eine '0' bedeutet, dass sie dieselben sind.
– uc_ehdr:
– nicht komprimierter ehdr: nicht komprimierter Kopfabschnitt mit Erweiterung Bormann (Herausgeber) [Seite 81] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
– komprimierter ehdr: komprimierter Kopfabschnitt mit Erweiterung, der den Kopfabschnitt mit Erweiterung an derselben Position in der ref_list wie die Referenz verwendet. Die Komprimierungsmechanismen für die verschiedenen Typen der Kopfabschnitte mit Erweiterung unterscheiden sich voneinander und von der FFS.

– Gen_id, resv, ref_id: dieselben wie im Abschnitt 3.2.1.2 definiert
– Änderungsbitmaske und uc_ehdr i: dieselbe wie für den R-Modus definiert

– resv: reserviert
– G: zeigt die Anwesenheit von Gen_id
– Gen_id: dieselbe wie in Abschnitt 3.2.1.2 definiert.
– im R-Modus ist gen_id nicht vorhanden.
– Während des Übergangs von irgend einem Modus in der U-Modus oder O-Modus sollte gen_id nicht gesendet werden. Die Liste ohne gen_id sollte nicht als eine Referenz verwendet werden, um einen Kopfabschnitt mit Erweiterung zu komprimieren und zu dekomprimieren.
– in UO-Modi ist gen_id vorhanden, wenn es als eine Referenz verwendet werden kann, um die nachfolgende Liste der Kopfabschnitte mit Erweiterung zu komprimieren oder zu dekomprimieren.

5.9 Kopfabschnittkomprimierungs-CRCs, Abdeckung und Polynome
Dieses Kapitel beschreibt, wie die CRCs zu berechnen sind, die in Paketkopf abschnitten verwendet werden, die in diesem Dokument definiert sind.
5.9.1 IR & IR-DYN Paket CRCs
Der CRC im IR und IR-DYN Paket wird über das gesamte IR oder IR-DYN Paket, ausschließlich der Nutzdaten und einschließlich der CID, berechnet. Für die Zwecke der Berechnung des CRC wird das CRC-Feld im Kopfabschnitt auf null gesetzt.
Der anfängliche Inhalt des CRC-Registers wird insgesamt auf 1 voreingestellt.
Das zu verwendende CRC-Polynom ist: C(x) = 1 + x + x^2 + x^8
5.9.2 CRCs in komprimierten Paketen
Der CRC in komprimierten Paketen wird über den gesamten ursprünglichen Kopfabschnitt vor der Komprimierung berechnet.
[[Anmerkung des Herausgebers: Beim WG-Treffen in Pittsburgh sagten wir, dass der Overhead der CRC-Berechnung durch das Berechnen des CRC zuerst über statische Teile des Pakets und dann über die dynamischen Teile reduziert werden kann. Dies muss hier im Detail spezifiziert werden.]]
Das für den 3 Bit CRC zu verwendende Polynom ist: C(x) = 1 + x + x^3
Das für den 7 Bit CRC zu verwendende Polynom ist: C(x) = ??? [muss definiert werden]Bormann (Herausgeber) [Seite 83]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
6. Implementierungsangelegenheiten
Dieses Dokument spezifiziert Mechanismen für das Protokoll, während der größte Teil der Verwendung dieser Mechanismen in der Entscheidung der implementierenden Personen belassen wird. Dieses Kapitel will Richtlinien, Ideen und Vorschläge für das Implementieren des Schemas geben.
6.1 Umgekehrte Dekomprimierung
Dieses Kapitel beschreibt einen optionalen Dekomprimiererbetrieb, um wegen eines ungültigen Kontexts verworfene Pakete zu reduzieren.
Wenn ein Kontext ungültig wird (beispielsweise wenn mehr aufeinanderfolgende Paketverluste als angenommen stattgefunden haben), so können nachfolgende komprimierte Pakete nicht sofort korrekt dekomprimiert werden. Die umgekehrte Dekomprimierung zielt auf eine spätere Dekomprimierung solcher Pakete ab, statt sie zu verwerfen, indem sie gespeichert werden, bis der Kontext aktualisiert und validiert wurde, und dann die Dekomprimierung versucht wird.
Die Sequenz gespeicherter Pakete sei i, i + 1, ..., i + k, wobei i das erste Paket ist, und i + k das Paket ist, bevor der Kontext aktualisiert wurde. Der Dekomprimierer wird versuchen, die gespeicherten Pakete in umgekehrter Reihenfolge, das heißt beginnend mit i + k und in Richtung auf i arbeitend, wieder zu gewinnen. Wenn ein gespeichertes Paket rekonstruiert wurde, wird seine Korrektheit unter Verwendung seines CRC verifiziert. Pakete, die keinen CRC tragen, dürfen nicht an obere Schichten geliefert werden. Pakete, bei denen die CRC gelingt, werden an die oberen Schichten in der ursprünglichen Reihenfolge, das heißt i, ..., i + k geliefert.
Man beachte, dass diese umgekehrte Dekomprimierung ein Zwischenspeichern einführt, während man darauf wartet, dass der Kontext validiert wird und somit eine zusätzliche Verzögerung einführt. Somit sollte sie nur verwendet werden, wenn eine gewisse Größe der Verzögerung akzeptabel ist. Beispielsweise verursacht bei Videopaketen, die zum selben Videobild gehören, die Verzögerung der Paketankunftszeiten keine Verzögerung der Präsentationszeit. Es kann auch sein, dass gegen Verzögerung unempfindliche Streaming-Anwendungen gegenüber einer solchen Verzögerung auch tolerant sind. Wenn der Dekomprimierer nicht bestimmen kann, ob die Anwendung eine Verzögerung tolerieren kann, sollte er die umgekehrte Dekomprimierung nicht durchführen.
Das Folgende zeigt das Dekomprimierungsverfahren im Detail:

1. Der Dekomprimierer speichert komprimierte Pakete, die durch einen ungültigen Kontext nicht korrekt dekomprimiert werden können.
2. Wenn der Dekomprimierer ein den Kontext aktualisierendes Paket empfangen hat, und wenn der Kontext validiert wurde, so beginnt er damit, die gespeicherten Pakete in umgekehrter Reihenfolge zurück zu gewinnen. Die Dekomprimierung wird ausgeführt, wobei man dem zuletzt dekomprimierten Paket zu seinem vorherigen Paket folgt, als ob die zwei Pakete neu geordnet wären. Danach prüft der Dekomprimierer die Korrektheit des rekonstruierten Kopfabschnitts unter Verwendung der CRC. Bormann (Herausgeber) [Seite 84] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000
3. Wenn die CRC eine erfolgreiche Dekomprimierung anzeigt, speichert der Dekomprimierer das komplette Paket und versucht das vorhergehende Paket zu dekomprimieren. Auf diese Weise werden die gespeicherten Pakete wieder gewonnen, bis keine komprimierten Pakete mehr übrig sind. Für jedes Paket prüft der Dekomprimierer die Korrektheit der dekomprimierten Kopfabschnitte unter Verwendung der Kopfabschnitt-Komprimierungs-CRC.
4. Wenn der CRC ein nicht korrekt dekomprimiertes Paket anzeigt, muss der Versuch der umgekehrten Dekomprimierung beendet werden, und alle verbleibenden, nicht komprimierten Pakete müssen verworfen werden.
5. Schließlich gibt der Dekomprimierer alle korrekt dekomprimierten Pakete an obere Schichten in der ursprünglichen Reihenfolge.

6.2 RTCP
RTCP ist das RTP-Steuerprotokoll, [RTP]. Das RTCP basiert auf periodischen Übertragungen der Steuerpakete an alle Teilnehmer in einer Sitzung, unter Verwendung desselben Verteilungsmechanismus wie für die Datenpakete. Seine primäre Funktion besteht darin, eine Rückkopplung von den Datenempfängern über die Qualität der Datenverteilung zu liefern. Die Rückkopplungsinformation kann für Aufgaben in Bezug auf Stockungssteuerfunktionen verwendet werden, und sie ist direkt nützlich für die Steuerung adaptiver Kodierungen.
In einer RTP-Sitzung wird es zwei Typen von Paketdatenströmen geben; einen mit dem RTP Kopfabschnitt und Anwendungsdaten, und einen zweiten Datenstrom mit der RTCP Steuerinformation. Der Unterschied zwischen den Strömen auf der Transportebene wird durch die UDP-Anschlussnummern dargestellt, die für das RTCP plus eins ist. Die Implementierung des ROHC Kopfabschnittkomprimierers besitzt verschiedene Wege, um den RTCP-Datenstrom zu handhaben.

1. Eine Komprimierer/Dekomprimierer-Einheit für beide Datenströme und auf demselben Kanal ausgeführt unter Verwendung von CIDs, um zwischen ihnen zu unterscheiden. Auf dem RTCP-Datenstrom wird im Grunde nur eine IP/UDP-Komprimierung verwendet.
2. Zwei Komprimierer/Dekomprimierer-Einheiten, eine für RTP und eine andere für RTCP, und die Datenströme werden auf ihren eigenen Kanälen befördert. Dies bedeutet, dass sie nicht denselben CID-Nummernraum teilen.

7. Weitere Arbeit
(Herausgeber: Dieser Abschnitt ist "weitere Arbeit", insbesondere da er in den Rest des Dokuments integriert werden muss).
7.3 Tunneln
7.3.1 Kopfabschnittkomprimierung für IPv4 Tunnelkopfabschnitt
Um die Pakete zum mobilen Knoten, der sich auf einer fremden Verbindung befindet, zu lenken, kann der Heimatagent des mobilen Knotens das ursprüngliche Paket in einen IP-Kopfabschnitt einkapseln und das Paket zur Betreuungsadresse (care-of adress) des mobilen Knotens tunneln. Im Falle einer Betreuungsadresse eines fremden Agenten im mobilen IPv4 wird der tunnelnde Kopfabschnitt in jedem getunnelten Paket durch den fremden Agenten entfernt, bevor er es zum mobilen Knoten durch die Luftschnittstelle befördert wird; somit besteht keine Notwendigkeit für die Komprimierung des tunnelnden Kopfabschnitts. In dem Fall, bei dem der mobile Knoten eine gemeinsam zugewiesene Betreuungsadresse verwendet, wird das getunnelte Paket zur mobilen Station durch die Luftschnittstelle gesandt, und eine Komprimierung muss auf den tunnelnden Kopfabschnitt angewandt werden.
7.3.1.1 Feldtyp des tunnelnden Kopfabschnitts beim mobilen IPv4
Die Tabelle unten fasst die Klassifikation der verschiedenen Felder, die in verschiedenen tunnelnden Kopfabschnitten definiert sind, die beim mobilen IPv4 verwendet werden, zusammen. In der Spalte des Einkapselungsschemas (Eink. Schema), sind drei Einkapselungsverfahren eingeschlossen: IP in IP Einkapselung (IIE), Minimum-Einkapselung (ME), allgemeine Verkehrslenkungseinkapselung (Generic Routing Encapsulation, GRE).
(Anmerkung des Herausgebers: Harmonisiere dies mit der Art, wie es im ROHC-Dokument beschrieben ist)

Bormann (Herausgeber) [Seite 86]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
7.3.1.2 Komprimierung der tunnelnden Kopfabschnitte in MIPv4
Drei Einkapselungsschemata wurden im MIPv4 spezifiziert. Für die verschiedenen Einkapselungsschemata unterscheiden sich die Komprimierungsverfahren voneinander.
7.3.1.2.1 IP in IP-Einkapselung in IPv4
Bei der Verwendung der IP in IP-Einkapselung wird der ursprüngliche innere IP-Kopfabschnitt überhaupt nicht modifiziert und kann somit komprimiert werden, als ob er nicht eingekapselt ist. Der äußere Kopfabschnitt wird auf der IP-Ebene komprimiert, während der innere Kopfabschnitt so komprimiert wird, wie das in der ROHC definiert ist.
7.3.1.2.2 Minimum-Einkapselung im IPv4
Bei der Minimum-Einkapselung wird der ursprüngliche IP-Kopfabschnitt modifiziert, und der Minimal-Vorwärts-Kopfabschnitt (Minimal Forwarding Header) wird zwischen den modifizierten IP-Kopfabschnitt und die ursprünglichen IP-Nutzdaten eingeschoben. Der modifizierte IP-Kopfabschnitt plus die UDP/RTP-Kopfabschnitte werden so komprimiert, wie das in der ROHC definiert ist.
Das Komprimierungsschema für den Minimal-Vorwärts-Kopfabschnitt ist ähnlich dem Schema, das auf den IP-Kopfabschnitt angewandt wird. Die statischen und die sich ändernden nicht wesentlichen Felder im Minimal-Vorwärts-Kopfabschnitt werden im Voll-Kopfabschnitt und Wiederauffrischungszustand gesendet. Wenn irgend eine Änderung bei irgend einem nicht wesentlichen Feld im Minimal-Vorwärts-Kopfabschnitt auftritt, sollte ein komprimierter Kopfabschnitt mit einer Bitmaske, die die Änderung anzeigt, gesendet werden.
7.3.1.2.3 Allgemeine Verkehrslenkungseinkapselung im IPv4
Bei der allgemeinen Verkehrslenkungseinkapselung wird das ursprüngliche IP-Paket in einem äußeren IP-Kopfabschnitt eingekapselt. Ein GRE-Kopfabschnitt wird zwischen den inneren Kopfabschnitt und den äußeren Kopfabschnitt eingeschoben. Der ursprüngliche IP/UDP/RTP-Kopfabschnitt wird komprimiert, als gäbe es keine Einkapselung. Der äußere IP-Kopfabschnitt wird auf der IP-Ebene komprimiert.
Bormann (Herausgeber) [Seite 87]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Das Komprimierungsschema für den GRE-Kopfabschnitt ist ähnlich dem Schema, das auf den IP-Kopfabschnitt angewandt wird. Alle die statischen und die sich ändernden nicht wesentlichen Felder im GRE-Kopfabschnitt werden im vollen Kopfabschnitt und Wiederauffrischungszustand gesendet. Wenn irgend eine Änderung in irgend einem nicht wesentlichen Feld im GRE-Kopfabschnitt auftritt, sollte ein komprimierter Kopfabschnitt mit einer Bitmaske, die die Änderung anzeigt, gesendet werden. Wenn die Sequenznummer im GRE-Kopfabschnitt vorhanden ist, könnte das Schema, um die Sequenznummer zu komprimieren, VLE sein, wie das im ACE-Entwurf definiert ist.
7.4 Nicht-RTP-UDP-Verkehr

(Anmerkung des Herausgebers: Dies ist Text von draft-koren-avt-crtp-enhance-01.txt, der dem ROHC hinzuzufügen ist – noch nicht konsistent mit dem Rest des Dokuments)
[Anmerkung von Micke: dies sollte ein getrenntes Profil sein].
[Anmerkung von Cabo: Ich bin mir nicht sicher, ob wir es überhaupt im ROHC behalten wollen. Das negative Cache-Flag sollte natürlich einfach dem I/R hinzugefügt werden, beispielsweise als ein Profil. Man beachte, dass Datenströme mit ungeraden Anschlussnummern nie RTP-Datenströme sein sollten, so dass dies berücksichtigt werden müsste, um die RTCP-Komprimierung zu vereinfachen. Ich bin nicht sicher, ob der Fall über e2e CRTP in Tunneln das ROHC stark betrifft. Wir müssen Zurückweisungspakete besser oben erläutern].

2.1 Das negative Cache-Datenstrom-Flag
Gewisse Datenströme, von denen bekannt ist oder vermutet wird, dass sie nicht RTP sind, können in einem "negativen Cache" beim Komprimierer platziert werden, so dass nur die IP- und UDP-Kopfabschnitte komprimiert werden. Es ist vorteilhaft, den Dekomprimierer darüber zu verständigen, dass sich der komprimierte Datenstrom im negativen Cache befindet: für solche Datenströme ist der Kontext kürzer – es besteht keine Notwendigkeit den RTP-Kopfabschnitt einzuschließen, und alle sich auf RTP beziehenden Berechnungen können vermieden werden.
Bei dieser Verbesserung wird ein neues Flag-Bit "N" dem Voll-Kopfabschnitt-Paket, das einen Kontext beim Dekomprimierer initialisiert, hinzugefügt. Das Bit, das durch das neue Flag belegt wird, wurde vorher immer auf null gesetzt. Wenn das N-Flag auf 1 gesetzt ist, so zeigt das an, dass nicht komprimierte RTP-Pakete in diesem Kontext übertragen werden. Dieses Flag ist nur eine Optimierung, und der Dekomprimierer kann wählen, es zu ignorieren.
[[Herausgeber: Das negative Cache-Flag könnte ein Teil der Profilinformation sein]]
2.2 Zurückweisen eines neuen komprimierten Datenstroms
In einer Punkt-zu-Punkt-Verbindung können sich die zwei Knoten über die Anzahl der komprimierten Sitzungen, die sie bereit sind, für diese Verbindung zu unterstützen, einigen. In einem Ende-zu-Ende-Schema kann ein Host komprimierte Sitzungen mit vielen Hosts haben und schließlich aus den Ressourcen laufen. Wenn ein Ende-zu-Ende-Tunnel ausgehandelt wird, kann es sein, dass die Anzahl der benötigten Kontexte nicht vorhersagbar ist. Diese Verbesserung erlaubt es, dass die ausgehandelte Anzahl der Kontexte größer ist, als sie untergebracht werden könnten, wenn viele Tunnel errichtet werden. Dann kann, wenn die Kontextressourcen aufgebraucht sind, ein Versuch, einen neuen Kontext zu errichten, zurückgewiesen werden.
Bormann (Herausgeber) [Seite 88]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Der Komprimierer initiiert eine Komprimierung eines Datenstroms durch das Senden eines Voll-Kopfabschnitt-Pakets. Wenn der Dekomprimierer aktuell ungenügend Ressourcen aufweist, um den neuen Datenstrom zu dekomprimieren, kann er ein Kontext-Zustand-Paket senden, um den neu komprimierten Datenstrom ungültig zu machen. Der Komprimierer kennt den Grund für das Ungültigmachen nicht: gewöhnlicherweise tritt dies auf, wenn der Dekomprimierer durch einen Paketverlust die Synchronisation verliert. Der Komprimierer wird sehr wahrscheinlich erneut versuchen, diesen Datenstrom zu komprimieren, indem er einen anderen Voll-Kopfabschnitt sendet.
Diese Verbesserung spezifiziert, dass der Dekomprimierer die Komprimierung eines Stroms zurückweisen kann, durch das Senden einer Zurückweisungsnachricht an den Komprimierer. Eine Zurückweisungsnachricht weist den Komprimierer an, das Komprimieren dieses Datenstroms zu stoppen.
Die Zurückweisungsnachricht ist eine [[Rückkoppelung-4 des Typs Zurückweisung]] mit einem zusätzlichen Flag:
Typkode = 1: Kontext-Zustand für 8 Bit CID-Datenströme
Typkode = 2: Kontext-Zustand für 16 Bit CID-Datenströme
[[Herausgeber: Dies wird durch das Zurückweisungs-Rückkopplungspaket gehandhabt]]
Der Komprimierer kann entscheiden, eine Weile zu warten, bevor er versucht, zusätzliche Datenströme, die für den zurückweisenden Host bestimmt sind, zu komprimieren.
Bormann (Herausgeber) [Seite 89]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
8. Abschnitt 8 wurde entfernt.
9. Sicherheitsbetrachtungen
Da eine Verschlüsselung die Redundanz eliminiert, die Kopfabschnittskomprimierungsschemata versuchen auszuwerten, besteht ein gewisser Anreiz, die Verschlüsselung von Kopfabschnitten voran zu treiben, um einen Betrieb über Verbindungen mit geringer Bandbreite zu, ermöglichen. Bei solchen Fällen jedoch, wo die Verschlüsselung der Daten (und nicht der Kopfabschnitte) ausreichend ist, spezifiziert das RTP ein alternatives Verschlüsselungsverfahren, bei dem nur die RTP-Nutzdaten verschlüsselt werden, und die Kopfabschnitte im klaren Zustand gelassen werden. Dies würde es dennoch ermöglichen, eine Kopfabschnittkomprimierung anzuwenden.
Die ROHC-Komprimierung ist transparent in Bezug auf die RTP-Sequenznummer und die RTP-Zeitstempel-Felder, so dass von Nutzdatenverschlüsselungsschemata auf die Werte solcher Felder vertraut werden kann.
Ein schlecht funktionierender oder böswilliger Kopfabschnittkomprimierer könnte den Kopfabschnittdekomprimierer veranlassen, Pakete wieder herzustellen, die nicht zu den ursprünglichen Paketen passen, aber dennoch gültige IP-, UDP- und RTP-Kopfabschnitte und möglicherweise sogar gültige UDP-Prüfsummen aufweisen. Eine solche Verstümmelung kann mit einer Ende-zu-Ende-Authentisierung und Integritätsmechanismen, die durch die Komprimierung nicht beeinträchtigt werden, detektiert werden. Darüber hinaus verwendet dieses Kopfabschnittkomprimierungsschema eine interne Prüfsumme für die Verifizierung von wieder erstellten Kopfabschnitten. Dies reduziert die Wahrscheinlichkeit für das Erzeugen dekomprimierter Kopfabschnitte, die nicht mit den ursprünglichen übereinstimmen, ohne dass dies bemerkt wird.
Ablehnung-eines-Dienstes-Angriffe sind möglich, wenn ein Eindringling (beispielsweise) gefälschte statische, dynamische oder Rückkopplungspakete auf der Verbindung einführt, und somit bewirkt, dass die Komprimierungseffizienz reduziert wird. Ein Eindringling, der die Fähigkeit besitzt, beliebige Pakete auf der Verbindungsschicht in dieser Weise einzuführen, macht jedoch zusätzliche Sicherheitsgesichtspunkte, die die, die sich auf die Verwendung der Kopfabschnittkomprimierung beziehen, in den Schatten stellen.
10. Danksagungen
Beim Gestalten dieses Protokolls sind frühere Ideen zur Kopfabschnittkomprimierung, die in [CJHC], [IPHC] und [CRTP] beschrieben wurden, wichtige Quellen der Information gewesen.
Dank an Takeshi Yoshimura am NTT DoCoMo für das Liefern des Abschnitts über die umgekehrte Dekomprimierung (6.1). Danke auch an Anton Martensson für viele wertvolle Entwurfsbeiträge und an Andreas Jonsson (Lulea Universität), der diese Arbeit mit seinem Studium von Änderungsmustern von Kopfabschnittsfeldern stark unterstützt hat. Danke auch an alle anderen, die Kommentare abgegeben haben.
Bormann (Herausgeber) [Seite 90]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
11. Betrachtungen bezüglich des geistigen Eigentums

(Anmerkung des Herausgebers: Dieser Abschnitt wird nach www.ietf.org/ipr gehen und durch die Standardreferenz ersetzt werden, aber bis jetzt wird er im Entwurf belassen, um das Arbeiten mit ihm zu erleichtern).

Dieser Vorschlag befindet sich in Übereinstimmung mit RFC 2026.
Telefonaktiebolaget LM Ericsson und seine Tochtergesellschaften werden gemäß der Firmenpolitik für Beiträge, die durch ihre Angestellten rechtmäßig angeboten werden, die als ein Standard durch die IETF angenommen oder empfohlen werden, eine Patentlizenz in folgender Weise anbieten:
Wenn ein Teile oder mehrere Teile von Beiträgen von Angestellten von Ericsson in eine Norm eingeschlossen wird oder werden, und Ericsson Patente und/oder Patentanmeldungen besitzt, die wesentlich für die Implementierung solcher eingeschlossenen Teile in dieser Norm sind, ist Ericsson bereit – auf der Basis der Gegenseitigkeit (Rückerstattung) – eine Lizenz auf solchen eingeschlossenen Teil oder solche eingeschlossene Teile zu gewähren zu vernünftigen, nicht diskriminierenden Bedingungen.
Um Zweifel zu vermeiden, wird diese allgemeine Zusicherung einer Patentlizenzvereinbarung auf diesen Vorschlag angewandt.
Nokia hat Patentanmeldungen eingereicht, die möglicherweise in technischer Beziehung zu diesem Beitrag stehen.
Matsushita hat Patentanmeldungen eingereicht, die möglicherweise in technischem Bezug zu diesem Beitrag stehen. Wenn ein Teil oder mehrere Teile des Beitrags von Angestellten von Matsushita in eine Norm eingeschlossen wird oder werden, und Matsushita Patente und/oder Patentanmeldungen, die wesentlich für die Implementierung eines oder mehrerer solcher eingeschlossenen Teile in diese Norm sind, besitzt, ist Matsushita bereit, – auf der Basis der Gegenseitigkeit (Rückerstattung) – eine Lizenz auf solchen eingeschlossenen Teil oder solche eingeschlossenen Teile zu gewähren, zu vernünftigen, nicht diskriminierenden Bedingungen (gemäß dem Paragraph 10.3.3 der RFC 2026).
NTT DoCoMo Inc. erklärt ebenfalls, dass dieser Text für ihr Patent relevant sein kann, und bietet eine Patentlizenz wie folgt an:
Wenn ein Teil oder mehrere Teile des Beitrags von Angestellten von NTT DoCoMo in eine Norm eingeschlossen wird oder werden, und NTT DoCoMo Patente und/oder Patentanmeldungen, die wesentlich für die Implementierung eines oder mehrerer solcher eingeschlossenen Teile in diese Norm sind, besitzt, ist NTT DoCoMo bereit, – auf der Basis der Gegenseitigkeit (Rückerstattung) – eine Lizenz auf solchen eingeschlossenen Teil oder solche eingeschlossenen Teile zu gewähren, zu vernünftigen, nicht diskriminierenden Bedingungen.
Bormann (Herausgeber) [Seite 91]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
12. Referenzen

[UDP] Jon Postel, "User Datagram Protocol", RFC 768, August 1980.
[IPv4] Jon Postel, "Internet Protocol", RFC 791, September 1981.
[IPv6] Steven Deering, Robert Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, Dezember 1998.
[RTP] Henning Schulzrinne, Stephen Casner, Ron Frederich, Van Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, Januar 1996.
[HDLC] William Simpson, "PPP in HDLC-like framing", RFC 1662, 1994.
[VJHC] Von Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, Februar 1990.
[IPHC] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header Compression", RFC 2507, Februar 1999.
[CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[PPPHC] Mathias Engan, Steven Casner, Carsten Vormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[CRTPC] Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister Svanbro, "CRTP ober cellular radio links", Internet Draft (work in progress), December 1999. <draft-degermark-crtp-cellular-01.txt>
[REQ] Mikael Degermark, "Requirements for robust IP/UDP/RTP header compression", Internet Draft (work in progress), June 2000. <draft-ietf-rohc-rtp-requirements-01.txt>
[LLG] Krister Svanbro, "Lower Layer Guidelines for Robust Header Compression", Internet Draft (work in progress), May 2000. <draft-ietf-rohc-lower-layer-guidelines-00.txt>
[CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic ober cellular access networks", Internet Draft (work in progress), May 2000 <draft-westberg-realtime-cellular-02.txt>

[WCDMA] "Universal Mobile Telecommunications Systems (UMTS); Selection procedures for the choice of radio transmission technologies of the UMTS (UMTS 30.03 version 3.1.0)". ETSI TR 101 112 V3.0.1, November 1997. Bormann (Herausgeber) [Seite 92] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000 13. Adressen der Autoren

Carsten Bormann Universität Bremen TZI Postfach 330440 D-28334 Bremen, Deutschland	Tel: +49 421 218 7024 Fax: +49 421 218 7000 EMail: cabo@tzi.org
Michael Degermark Universität von Arizona Dept of Computer Science P. O. Box 210077 Tucson, AZ 85721-0077, USA	Tel: +1 520 621-3498 Fax: +1 520 621-4642 EMail: micke@cs-arizona.edu
Lars-Erik Jonsson Ericsson Erisoft AB SE-971 28 Lulea, Schweden	Tel: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars_erik.jonsson@ericsson.com
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA	Tel: +1 972 894-5935 Fax: +1 972 894-4589 EMail: zhigang.liu@nokia.com

Bormann (Herausgeber) [Seite 93] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

Anhang A: Detaillierte Klassifikation von Kopfabschnittsfeldern
Die Kopfabschnittkomprimierung ist möglich durch die Tatsache, dass die meisten Kopfabschnittsfelder sich von Paket zu Paket nicht zufällig ändern. Viele dieser Felder zeigen ein statisches Verhalten oder Änderungen, die mehr oder weniger vorhersagbar sind. Bei der Gestaltung eines Kopfabschnittskomprimierungsschemas ist es von fundamentaler Wichtigkeit, das Verhalten dieser Felder im Detail zu verstehen.
In diesem Anhang werden alle IP-, UDP- und RTP-Kopfabschnittsfelder in zwei Stufen klassifiziert und analysiert. Zuerst haben wir eine allgemeine Klassifizierung in A.1, wo die Felder auf der Basis einer stabilen Kenntnis und von Annahmen klassifiziert werden. Die allgemeine Klassifikation berücksichtigt nicht die Änderungseigenschaften der sich ändernden Felder, da diese mehr oder weniger in Abhängigkeit von der Implementierung und der verwendeten Anwendung variieren werden. Eine weniger stabile aber detailliertere Analyse, die die Änderungseigenschaften berücksichtigt, wird dann in A.2 vorgenommen. Schließlich fasst A.3 diesen Anhang zusammen mit Schlussfolgerungen, wie die verschiedenen Kopfabschnittsfelder durch das Kopfabschnittskomprimierungsschema gehandhabt werden sollten, um die Komprimierung und die Funktionalität zu optimieren.
A.1 Allgemeine Klassifikation
Auf einer allgemeinen Ebene werden die Kopfabschnittsfelder in 5 Klassen aufgeteilt:
ABGELEITET Diese Felder enthalten Werte, die von anderen Werten abgeleitet werden können, beispielsweise die Größe des Rahmens, der das Paket befördert, und sie müssen somit nicht alle durch das Komprimierungsschema gehandhabt werden.
STATISCH Es wird erwartet, dass diese Felder während der Lebensdauer des Paketdatenstroms konstant sind. Statische Information muss auf irgend eine Weise einmal übertragen werden.
STATISCH-DEF Statische Felder, deren Werte einen Paketdatenstrom definieren. Sie werden im allgemeinen als statisch gehandhabt.
STATISCH-BEKANNT Von diesen statischen Feldern wird erwartet, das sie wohl bekannte Werte aufweisen und sie somit überhaupt nicht übertragen werden müssen.
ÄNDERND Von diesen Feldern wird erwartet, dass sie sich auf eine gewisse Weise ändern, entweder zufällig innerhalb eines begrenzenden Wertesatzes oder Bereichs oder auf irgend eine andere Weise.
In diesem Abschnitt wird jedes der IP-, UDP- und RTP-Kopfabschnittsfelder einer dieser Klassen zugewiesen. Für alle Felder, mit Ausnahme derer, die als ÄNDERND klassifiziert sind, sind die Motive für die Klassifikation auch angegeben. Sich ändernde Felder werden in A.2 weiter untersucht und klassifiziert auf der Basis ihres erwarteten Änderungsverhaltens.
Bormann (Herausgeber) [Seite 94]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
A.1.1 IPv6 Kopfabschnittsfelder
Version
Das Versionsfeld gibt an, auf welcher IP-Version das Paket basiert. Pakete mit unterschiedlichen Werten in diesem Feld müssen von unterschiedlichen IP-Stapeln gehandhabt werden. Für die Kopfabschnittkomprimierung müssen auch verschiedene Komprimierungsprofile verwendet werden. Wenn der Komprimierer und der Dekomprimierer ausgehandelt haben, welches Profil zu verwenden ist, ist auch die IP-Version beiden Parteien bekannt. Dieses Feld wird somit als STATISCH-BEKANNT klassifiziert.
Flussmarkierung
Dieses Feld kann verwendet werden, um Pakete zu identifizieren, die zu einem spezifischen Paketdatenstrom gehören. Wenn es nicht verwendet wird, sollte der Wert auf null gesetzt werden. Ansonsten müssen alle Pakete, die zum selben Datenstrom gehören, denselben Wert in diesem Feld aufweisen, wobei es eines der Felder ist, die den Datenstrom definieren. Das Feld wird somit als STATISCH-DEF klassifiziert.
Nutzdatenlänge
Es wird erwartet, dass Information über die Paketlänge (und dann auch die Nutzdatenlänge) von der Verbindungsschicht geliefert wird. Dieses Feld wird somit als ABGELEITET klassifiziert.
Nächster Kopfabschnitt
Es wird erwartet, dass dieses Feld denselben Wert in allen Paketen eines Paketdatenstroms aufweist. Wie bei der Versionsnummer kann ein gewisses Komprimierungsprofil nur einen spezifischen nächsten Kopfabschnitt handhaben, was bedeutet, dass dieser Wert bekannt ist, wenn ein Profil ausgehandelt wurde. Das Feld wird somit als STATISCH-BEKANNT klassifiziert.
Bormann (Herausgeber) [Seite 95]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Quellen- und Zieladressen
Diese Felder sind Teil der Definition eines Datenstroms und müssen somit für alle Pakete im Datenstrom konstant sein. Diese Felder werden somit als STATISCH-DEF klassifiziert.
Eine Zusammenfassung der Bits, die den Klassen entsprechen, ergibt:
A.1.2. IPv4 Kopfabschnittsfelder
Version
Das Versionsfeld gibt an, auf welcher IP-Version das Paket basiert, und Pakete mit unterschiedlichen Werten in diesem Feld müssen durch unterschiedliche IP-Stapel gehandhabt werden. Für eine Kopfabschnittskomprimierung müssen auch verschiedene Komprimierungsprofile verwendet werden. Wenn der Komprimierer und der Dekomprimierer ausgehandelt haben, welches Profil zu verwenden ist, ist beiden Parteien auch die IP-Version gut bekannt. Das Feld wird daher als STATISCH-BEKANNT klassifiziert.
Bormann (Herausgeber) [Seite 96]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Kopfabschnittslänge
Solange keine Optionen im IP-Kopfabschnitt vorhanden sind, ist die Kopfabschnittslänge konstant und gut bekannt. Wenn es Optionen gibt, würden die Felder STATISCH sein, aber wir nehmen an, dass es keine Optionen gibt. Das Feld wird somit als STATISCH-BEKANNT klassifiziert.
Paketlänge
Es wird erwartet, dass Information über die Paketlänge durch die Verbindungsschicht geliefert wird. Das Feld wird daher als ABGELEITET klassifiziert.
Flags
Das reservierte Flag muss auf null gesetzt werden und ist deshalb als STATISCH-BEKANNT klassifiziert. Das May-Fragment-Flag wird für alle Pakete in einem Datenstrom konstant sein und wird somit als STATISCH klassifiziert. Schließlich wird erwartete, dass das Letztes-Fragment-Bit null ist, da eine Fragmentierung durch die erwartete kleine Paketgröße nicht erwartet wird. Das Letze-Fragment-Bit wird somit als STATISCH-BEKANNT klassifiziert.
Fragment-Versatz
Mit der Annahme, dass keine Fragmentierung auftritt, ist der Fragmentversatz immer null. Das Feld wird somit als STATISCH-BEKANNT klassifiziert.
Protokoll
Es wird erwartet, dass dieses Feld in allen Paketen eines Paketdatenstroms denselben Wert hat. Wie bei der Versionsnummer kann ein gewisses Komprimierungsprofil nur einen spezifischen nächsten Kopfabschnitt handhaben, was bedeutet, dass dieser Wert wohl bekannt ist, wenn das Profil ausgehandelt wurde. Das Feld wird somit als STATISCH-BEKANNT klassifiziert.
Kopfabschnitt-Prüfsumme
Die Kopfabschnittsprüfsumme schützt die einzelnen Sprünge vor der Verarbeitung eines verstümmelten Kopfabschnitts. Wenn nahezu alle IP-Kopfabschnittinformation komprimiert ist, besteht keine Notwendigkeit für diese zusätzliche Prüfsumme; stattdessen kann sie auf der Seite des Dekomprimierers regeneriert werden. Das Feld wird somit als ABGELEITET klassifiziert.
Bormann (Herausgeber) [Seite 97]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Quellen- und Zieladressen
Diese Felder sind Teil der Definition eines Datenstroms und müssen somit für alle Pakete im Datenstrom konstant sein. Diese Felder werden somit als STATISCH-DEF klassifiziert.
Eine Zusammenfassung der Bits, die den Klassen entsprechen, ergibt:
A.1.3 UDP-Kopfabschnittsfelder
Quellen- und Zielanschlüsse
Diese Felder sind ein Teil der Definition eines Datenstroms und müssen somit für alle Pakete im Datenstrom konstant sein. Diese Felder werden daher als STATISCH-DEF klassifiziert.
Länge
Dieses Feld ist redundant und wird somit als ABGELEITET klassifiziert.
Eine Zusammenfassung der Bits, die den Klassen entsprechen, ergibt:
Bormann (Herausgeber) [Seite 98]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
A.1.4. RTP-Kopfabschnittsfelder
Version
Es existiert nur eine arbeitende RTP-Version und das ist die Version 2. Das Feld wird somit klassifiziert als STATISCH-BEKANNT.
Auffüllen
Die Verwendung dieses Felds hängt von der Anwendung ab, aber wenn ein Nutzlastauffüllen verwendet wird, ist es wahrscheinlich, dass es in allen Paketen vorhanden ist. Das Feld wird somit als STATISCH klassifiziert.
Erweiterung
Wenn RTP-Erweiterungen von der Anwendung verwendet werden, ist es wahrscheinlich, dass eine Erweiterung in allen Paketen vorhanden ist (aber die Verwendung von Erweiterungen ist sehr ungebräuchlich). Aus Gründen der Sicherheit wird dieses Feld jedoch als STATISCH und nicht als STATISCH-BEKANNT klassifiziert.
SSRC
Dieses Feld ist ein Teil der Definition eines Datenstroms und muss somit für alle Pakete im Datenstrom konstant sein. Das Feld wird daher als STATISCH-DEF klassifiziert.
Bormann (Herausgeber) [Seite 99]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Eine Zusammenfassung der Bits, die den Klassen entsprechen, ergibt:
A.1.5. Zusammenfassung für IP/UDP/RTP
Wenn wir dies für IP/UDP/RTP zusammenfassen erhalten wir:
A.2 Analyse der Änderungsmuster der Kopfabschnittsfelder
Um geeignete Mechanismen für eine effiziente Komprimierung aller Kopfabschnittsfelder zu gestalten, müssen ihre Änderungsmuster analysiert werden. Aus diesem Grund wird eine erweiterte Klassifikation auf der Basis der allgemeinen Klassifikation in A.1 ausgeführt, unter Berücksichtigung der Felder, die in dieser Klassifikation mit ÄNDERND bezeichnet sind. Verschiedene Anwendungen werden die Felder auf unterschiedliche Arten verwenden, was ihr Verhalten beeinflussen kann. Wenn dies der Fall ist, so wird ein typisches Verhalten für Dialog-Audio und Video diskutiert.
Die sich ändernden Felder werden in fünf unterschiedliche Unterklassen aufgeteilt:
STATISCH: Diese sind Felder, die als ÄNDERND auf einer allgemeinen Basis klassifiziert wurden, aber sie werden hier als STATISCH klassifiziert, aufgrund verschiedener zusätzlicher Annahmen.
HALBSTATISCH: Diese Felder sind die meiste Zeit statisch. Gelegentlich ändert sich jedoch ihr Wert, aber kehrt zur seinem ursprünglichen Wert nach einer bekannten Anzahl von Paketen zurück.
Bormann (Herausgeber) [Seite 100]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
SELTEN-ÄNDERND (RC): Dies sind Felder, die ihre Werte gelegentlich ändern und dann ihre neuen Werte beibehalten.
WECHSELND: Diese Felder wechseln zwischen einer kleinen Anzahl unterschiedlicher Werte.
UNREGELMÄSSIG: Dies sind schließlich Felder, für die kein verwendbares Änderungsmuster identifiziert werden kann.
Um die Klassifikationsmöglichkeiten weiter auszudehnen, ohne die Komplexität zu erhöhen, kann die Klassifikation entweder gemäß den Werten des Feldes und/oder gemäß den Werten der Deltas für das Feld durchgeführt werden.
Wenn die Klassifikation ausgeführt wird, werden andere Details auch ausgeführt im Hinblick auf mögliche zusätzliche Kenntnis über die Feldwerte und/oder Felddeltas gemäß der Klassifikation. Für Felder, die als statisch oder halbstatisch klassifiziert sind, kann der Fall auftreten, dass der Wert des Feldes nicht nur statisch sondern auch a priori wohl bekannt ist (zwei Zustände für halbstatische Felder). Für Felder mit einem nicht unregelmäßigen Änderungsverhalten, könnte bekannt sein, dass Änderungen gewöhnlicherweise innerhalb eines begrenzten Bereichs im Vergleich zur maximalen Änderung für das Feld liegen. Für andere Felder sind die Werte vollständig unbekannt.
Bormann (Herausgeber) [Seite 101]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Tabelle A.1 klassifiziert alle sich ändernden Felder auf der Basis ihrer erwarteten Änderungsmuster, insbesondere für Dialog-Audio und Video.
Tabelle A.1: Klassifikation von sich ändernden Kopfabschnittsfeldern
Die folgenden Unterabschnitte diskutieren die verschiedenen Kopfabschnittsfelder im Detail. Man beachte, dass Tabelle A.1 und die nachfolgenden Diskussionen Änderungen, die durch einen Verlust oder eine Neuordnung vor dem Komprimierungspunkt verursacht werden, nicht berücksichtigen.
A.2.1 IPv4 Identifikation
Das Identifikationsfeld (IP ID) des IPv4 Kopfabschnitts ist dazu da, zu identifizieren, welche Fragmente ein Datagramm bilden, wenn fragmentierte Datagramme wieder zusammengefügt werden. Die IPv4 Spezifikation spezifiziert nicht exakt, wie diesem Feld Werte zuzuweisen sind, sondern nur, dass jedes Paket eine IP ID erhalten sollte, die für das Quelle-Ziel-Paar eindeutig ist, und das Protokoll für die Zeit des Datagramms (oder irgend eines seiner Fragmente) könnte im Netzwerk am Leben sein. Dies bedeutet, dass die Zuweisung von IP ID Werten auf verschiedene Arten erfolgen kann, die in drei Klassen getrennt werden.
Sequentiell: Diese Zuweisungsart führt einen getrennten Zähler für jeden nach außen gehenden Paketdatenstrom, und somit wird der IP ID Wert für jedes Paket im Datenstrom um eins erhöht. Somit ist der Deltawert des Feldes konstant und im Vorhinein gut bekannt. Wenn RTP auf UDP und IP verwendet wird, folgt der IP ID Wert der RTP Sequenznummer. Diese Zuweisungsart ist für die Zwecke der Kopfabschnittskomprimierung die wünschenswerteste, aber ihre Verwendung ist nicht so üblich, wie es sein sollte. Der Grund dafür ist, dass sie nur verwirklicht werden kann, wenn UDP und IP zusammen implementiert werden, so dass das UDP, das Paketdatenströme nach der Anschlussidentifikation trennt, bewirken kann, dass das IP getrennte ID-Zähler für jeden Paketdatenstrom verwendet.
Bormann (Herausgeber) [Seite 102]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Sequentieller Sprung: Dies ist die häufigste Zuweisungsart bei den heutigen IP-Stapeln. Der Unterschied zum sequentiellen Verfahren besteht darin, dass nur ein Zähler für alle Verbindungen verwendet wird. Wenn der Sender mehr als einen Paketdatenstrom gleichzeitig laufen lässt, kann die IP ID um mehr als eins zunehmen. Die IP ID Werte werden viel vorhersagbarer sein und erfordern weniger Bits für die Übertragung als Zufallswerte, und die Paket-zu-Paket-Inkrementierung (bestimmt durch die Anzahl der aktiven, nach außen gehenden Paketströme und Sendefrequenzen) wird gewöhnlicherweise begrenzt sein.
Zufällig: Einige IP-Stapel weisen IP ID Werte unter Verwendung eines Pseudozufallszahlengenerators zu. Es besteht keine Korrelation zwischen den ID-Werten der nachfolgenden Datagramme. Somit gibt es keinen Weg, den IP ID Wert für das nächste Datagramm vorherzusagen. Für die Zwecke der Kopfabschnittskomprimierung bedeutet dies, dass das IP ID Feld unkomprimiert mit jeden Datagramm gesendet werden muss, was zu zwei zusätzlichen Oktetts des Kopfabschnitts führt. IP-Stapel in zellularen Endgeräten sollten diese IP ID Zuweisungsart nicht verwenden.
Es sollte angemerkt werden, dass die ID ein IPv4 Mechanismus ist und somit in IPv6 Profilen überhaupt nicht benötigt wird. Für IPv4 könnte die ID auf drei verschiedene Arten gehandhabt werden. Zuerst haben wir die ineffiziente aber zuverlässige Lösung, bei der das ID-Feld so wie es ist, in allen Paketen gesendet wird, was die komprimierten Kopfabschnitt um zwei Oktette erhöht. Dies ist der beste Weg, das ID-Feld handzuhaben, wenn der Sender eine zufällige Zuweisung des ID-Feldes verwendet. Als zweites kann es Lösungen mit flexibleren Mechanismen geben, die weniger Bits für die ID-Handhabung benötigen, so lange eine sequentielle Sprungzuweisung verwendet wird. Solche Lösungen werden wahrscheinlich sogar mehr Bits erfordern, wenn eine zufällige Zuweisung vom Sender verwendet wird. Kenntnis über die Zuweisungsart des Senders könnte somit nützlich sein, wenn eine Wahl zwischen den zwei obigen Lösungen vorgenommen wird. Schließlich kann sogar für IPv4 die Kopfabschnittkomprimierung gestaltet werden, ohne dass zusätzliche Information für das ID-Feld in den komprimierten Kopfabschnitten eingefügt wird. Um solche Schemata zu verwenden, muss bekannt sein, dass der Sender eine reine sequentielle Zuweisungsart für das ID-Feld verwendet. Es kann sein, dass es nicht möglich ist, dies zu wissen, was bedeutet, dass die Anwendbarkeit solcher Lösungen sehr unsicher ist. Gestalter der IPv4-Stapel für zellulare Endgeräte sollten jedoch die sequentielle Zuweisungsart verwenden.
A.2.2 IP-Verkehrsklasse/Typ des Dienstes
Es wird erwartet, dass das Feld der Verkehrsklasse (IPv6) oder des Typs des Dienstes (IPv4) während der Lebensdauer eines Paketdatenstroms konstant ist oder sich relativ selten ändert.
Bormann (Herausgeber) [Seite 103]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
A.2.3. IP Sprungbegrenzung/Lebensdauer
Es wird erwartet, dass das Feld der Sprungbegrenzung (IPv6) oder der Lebensdauer (IPv4) während der Lebensdauer eines Paketdatenstroms konstant ist oder zwischen einer begrenzten Anzahl von Werten durch Routenänderungen wechselt.
A.2.4 UDP-Prüfsumme
Die UDP-Prüfsumme ist optional. Wenn sie gesperrt ist, ist ihr Wert konstant null und könnte völlig unterdrückt werden. Wenn sie aktiv ist, hängt ihr Wert von den Nutzdaten ab, was für die Zwecke der Komprimierung äquivalent ist dazu, dass sie sich zufällig mit jedem Paket ändert.
A.2.5. RTP CSRC Zähler
Dies ist ein Zähler, der die Anzahl der CSRC-Gegenstände, die in der CSRC-Liste vorhanden sind, anzeigt. Es wird erwartet, dass diese Anzahl nahezu konstant auf einer Paket-zu-Paket-Basis ist, und sich nur um einen kleinen Betrag ändert. So lange wie kein RTP-Mischer verwendet wird, ist der Wert dieses Feldes null.
A.2.6. RTP-Markierung
Für Audio sollte das Markierungsbit nur im ersten Paket eines Gesprächsstoßes gesendet werden, während es für Video im letzten Paket jedes Bildes gesendet werden sollte. Das bedeutet, dass in beiden Fällen die RTP-Markierung als halbstatisch mit wohl bekannten Werten für beide Zustände klassifiziert wird.
A.2.7 RTP-Nutzdatentyp
Es wird erwartet, dass Änderungen des RTP-Nutzdatentyps innerhalb eines Paketstroms selten sind. Anwendungen können eine Anpassungen an Staus vornehmen, indem sie den Nutzdatentyp und/oder die Rahmengrößen ändern, aber es wird nicht erwartet, dass das häufig auftritt.
A.2.8. RTP-Sequenznummer
Die RTP-Sequenznummer wird um eins für jedes gesendete Paket erhöht.
A.2.9. RTP-Zeitstempel
Im Audiofall: So lange es keine Pausen im Audiodatenstrom gibt, wird der RTP-Zeitstempel um ein konstantes Delta erhöht, das der Anzahl der Abtastungen im Sprachrahmen entspricht. Er wird somit hauptsächlich der RTP-Sequenznummer folgen. Wenn es eine ruhige Periode gegeben hat, und ein neuer Gesprächsstoß beginnt, wird der Zeitstempel im Verhältnis zur Länge der ruhigen Periode springen. Das Inkrement wird jedoch wahrscheinlich innerhalb eines relativ begrenzten Bereichs liegen.
Bormann (Herausgeber) [Seite 104]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Im Videofall: Der Zeitstempel zwischen zwei aufeinanderfolgenden Paketen wird entweder null sein oder sich um ein Vielfaches eines festen Werts erhöhen, der der Bildtaktfrequenz entspricht. Der Zeitstempel kann sich auch tun ein Vielfaches des festen Wertes erniedrigen, wenn B-Bilder verwendet werden. Das Deltaintervall, ausgedrückt als ein Vielfaches der Bildtaktfrequenz, ist in den meisten Fällen sehr begrenzt.
A.2.10 RTP Beitragende Quellen (CSRC)
Es wird angenommen, dass die Teilnehmer einer Sitzung, die durch die CSRC-Felder identifiziert werden, auf einer Paket-zu-Paket-Basis nahezu dieselben sind mit relativ wenigen Hinzufügungen oder Entfernungen. So lange keine RTP Mischer verwendet werden, sind überhaupt keine CSRC-Felder vorhanden.
A.3 Strategien zur Kopfabschnittskomprimierung
Dieser Abschnitt arbeitet das aus, was in früheren Abschnitten erfolgt ist. Basierend auf den Klassifikationen werden Empfehlungen gegeben, wie die verschiedenen Felder im Kopfabschnittskomprimierungsverfahren handzuhaben sind. Sieben verschiedene Aktionen sind möglich und diese sind zusammen mit den Feldern, auf die sich jede Aktion bezieht, aufgelistet.
A.3.1 Überhaupt kein Senden
Die Felder, die a priori wohl bekannte Werte haben, müssen überhaupt nicht gesendet werden. Diese sind:

– IP Version
– IPv6 Nutzdatenlänge
– IPv6 Nächster Kopfabschnitt
– IPv4 Kopfabschnittslänge
– IPv4 reserviertes Flag
– IPv4 letztes Fragment-Flag
– IPv4 Fragmentversatz
– IPv4 Protokoll
– UDP-Prüfsumme (wenn gesperrt)
– RTP-Version

A.3.2 Übertragung nur anfänglich
Die Felder, die während der Lebenszeit des Paketdatenstroms konstant sind, müssen nur einmal an den Dekomprimierer übertragen und korrekt geliefert werden. Diese sind:

– IP Quellenadresse
– IP Zieladresse
– IPv6 Flussmarkierung
– IPv4 May-Fragment-Flag
– UDP Quellenanschluss
– UDP Zielanschluss
– RTP Auffüllungs-Flag
– RTP Erweiterungsflag
– RTP SSRC

A.3.3. Übertrage anfänglich aber bereit für Aktualisierung
Die Felder, die sich nur gelegentlich ändern, müssen anfänglich übertragen werden, aber es muss auch einen Weg geben, um diese Felder mit neuen Werten zu aktualisieren, wenn sie sich ändern. Diese Felder sind:

– IPv6 Verkehrsklasse
– IPv6 Sprunggrenze
– IPv4 Typ des Dienstes (TOS)
– IPv4 Lebensdauer (TTL)
– RTP CSRC Zähler
– RTP Nutzdatentyp
– RTP CSRC Liste

A.3.4. Vorbereitet für Aktualisierung oder häufiges Senden, so wie es ist
Für Felder, die normalerweise entweder konstant sind oder deren Werte aus einem anderen Feld abgeleitet werden können, aber die häufig von diesem Verhalten abweichen, muss es einen effizienten Weg geben, um den Feldwert zu aktualisieren oder ihn, so wie er ist, in einigen Paketen zu senden. Solche Felder sind:

– IPv4 Identifikation (wenn nicht sequentiell zugewiesen)
– RTP Markierung
– RTP Zeitstempel

A.3.5. Garantie kontinuierlicher Robustheit
Für Felder, die sich wie ein Zähler mit einem festen Delta für alle Pakete verhalten, besteht die einzige: Anforderung bei der Übertragungskodierung, dass die Paketverluste zwischen Komprimierer und Dekomprimierer tolerierbar sein müssen. Wenn mehr als ein solches Feld existiert, können die zusammen übertragen werden. Solche Felder können auch verwendet werden, um die Werte für die Felder, die im vorherigen Abschnitt aufgeführt sind, zu interpretieren.
Bormann (Herausgeber) [Seite 106]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
Felder, die dieses Zählerverhalten aufweisen, sind:

– IPv4 Identifikation (wenn sequentiell zugewiesen)
– RTP Sequenznummer

A.3.6. Übertragen, wie es ist, in allen Paketen
Felder, die vollständig zufällige Werte für jedes Paket aufweisen, müssen, so wie sie sind, in alle komprimierten Kopfabschnitte eingefügt werden. Solche Felder sind:

– IPv4 Identifikation (wenn zufällig zugewiesen)
– UDP Prüfsumme (wenn aktiviert)

A.3.7. Errichten von Delta und Bereit zur Aktualisierung
Schließlich gibt es ein Feld, das gewöhnlicherweise um ein festes Delta zunimmt, und das zu einem anderen Feld in Korrelation steht. Für dieses Feld macht es Sinn, dieses Delta zu einem Teil des Kontextzustands zu machen. Es muss dann möglich sein, das Delta auf dieselbe Art wie die Felder, die in A.3.3. aufgeführt sind, zu initiieren und zu aktualisieren. Das Feld, auf das dies zutrifft, ist

– RTP Zeitstempel

E.1 Grund VLE
Die Beispiele unten zeigen den Betrieb des VLE unter verschiedenen Szenarien. Die Feldwerte, die in den Beispielen verwendet werden, könnten jeglichen Feldern, die man zu komprimieren wünscht, entsprechen. Die Beispiele zeigen das Szenarium, bei dem das komprimierte Feld eine Auflösung von einem Bit aufweist.
Beispiel 1: Normaler Betrieb (kein Paketverlust vor dem Komprimierer, keine Neuordnung vor dem Komprimierer)
Man nehme an, dass Pakete mit den Kopfabschnittfeldern 279, 280, 281, 282 und 283 gesendet wurden, wobei 279 und 283 Felder möglicher Referenzpakete sind.
Das aktuelle VLE-Fenster ist {279, 283}
Ein Paket mit dem Feldwert = 284 wird als nächstes empfangen. VLE berechnet die folgenden Werte:
Das Fenster ist nicht modifiziert, wenn wir annehmen, dass das neue Paket {284} nicht eine mögliche Referenz darstellt. Das Feld wird kodiert unter Verwendung von 4 Bits in diesem Fall, und der tatsächlich kodierte Wert wird durch die 4 niederwertigsten Bits von 284 (10011100) dargestellt, beträgt somit 1100.
Beispiel 2: Paketverlust vor dem Komprimierer
Man nehme an, dass Pakete mit den Kopfabschnittfeldern 279, 280, 281, 282 und 283 gesendet wurden, und 271 und 283 sind Felder möglicher Referenzpakete, so dass das VSM wiederum {279, 283} ist.
Wenn ein Paket mit dem Feldwert = 290 als nächstes empfangen wird, so berechnet VLE die folgenden Werte:
So wird das Feld unter Verwendung von 5 Bits kodiert. Der tatsächlich kodierte Wert sind die 5 LSBs von 290 (100100010), die somit 00010 betragen.
Wenn wir annehmen, dass der neue Wert eine mögliche Referenz ist, so ist das neue VSW {279, 283, 290}.
Beispiel 3: Paketfehlordnung vor dem Komprimierer

Bormann (Herausgeber) [Seite 108] INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung 18. September 2000

Man nehme an, dass Pakete mit dem Kopfabschnittfeldern 279, 280, 281, 282 und 283 gesendet wurden, und 279 und 283 sind Felder möglicher Referenzpakete, so dass das VSM wiederum {279, 283} ist.
Wenn ein Paket mit dem Feldwert = 278 als nächstes empfangen wird, so berechnet VLE die folgenden Werte:
So wird das Feld unter Verwendung von 4 Bits kodiert. Der tatsächlich kodierte Wert sind die 4 LSBs von 278 (10010110), die somit 0110 betragen.
Wenn wir annehmen, dass der neue Wert eine mögliche Referenz ist, so ist das neue VSW {283, 290, 278}.
In jedem Fall müssen die VLE kodierten Felder durch einige Bits begleitet werden, um die verschiedenen möglichen kodierten Feldgrößen zu identifizieren. Die Größen dieses Bitfeldes können in Abhängigkeit von der Zahl der verschiedenen Größen, die man gestatten will, variieren. Die Lösung bei ACE besteht darin, nur einige wenige unterschiedliche Größen für Byte-ausgerichtete Kopfabschnittformate zu gestatten. Eine Huffman-Kodierung der Länge wird verwendet, um eine zusätzliche Effizienz zu erzielen, basierend auf der erwarteten Frequenz der Benötigung der verschiedenen Größen. 1 oder 2 zusätzliche Bits werden tatsächlich im ACE komprimierten Kopfabschnitt gesendet.
Das Verhalten des Dekomprimierers in allen Beispielfällen ist dasselbe – er verwendet als eine Referenz einen spezifischen dekomprimierten Kopfabschnittsfeldwert. Der zu verwendenden Kopfabschnitt kann durch das Vorhandensein einer Prüfsumme im komprimierten Kopfabschnittspaket oder durch andere Mittel angezeigt werden. Sie müssen per Definition einer der Werte im Fenster des Komprimierers sein.
Man nehme beispielsweise an, dass das letzte korrekt dekomprimierte Paket, das sich als eine Referenz qualifiziert, das Paket war mit dem Kopfabschnittsfeld = 291. Man nehme nun an, dass der kodierte Feldwert von 303 (10001111) empfangen wird, und LSBs = 01111. Die zwei Werte, die am dichtesten zu 291 liegen, die LSBs = 01111 haben, sind 271 und 303. 303 liegt am dichtesten, somit wird es korrekt als unkomprimierter Feldwert ausgewählt.
E.2 Auf einem Zeitgeber basierende VLE
Als ein Beispiel des Betriebs sei der Fall eines Sprach-Kodierers/Dekodierers (20 ms) angenommen, bei dem der TS_Schritt = 160 ist. Man nehme an, dass T_aktuell und p_TS_aktuell 357 beziehungsweise 351 sind, und dass wir ein gleitendes Fenster TSW haben, das die folgenden 4 Werteeinträge enthält
Bormann (Herausgeber) [Seite 109]
INTERNET-ENTWURF Robuste Kopfabschnittskomprimierung
18. September 2000
j oben ist die Paketnummer.
In diesem Fall haben wir: Netzwerk_Schwankung(1) = |(357 – 9) – (351 – 7)| = 4 (80 ms Schwankung) Netzwerk_Schwankung(2) = |(357 – 8) – (351 – 6)| = 4 (80 ms Schwankung) Netzwerk_Schwankung(3) = |(357 – 7) – (351 – 4)| = 3 (60 ms Schwankung) Netzwerk_Schwankung(4) = |(357 – 3) – (351 – 1)| = 4 (80 ms Schwankung)
So ist Max_Netzwerk Schwankung = 4.
Wir nehmen eine maximale CD-CC Schwankung von 2 (40 ms) an, so ist die gesamte Schwankung, die in diesem Fall gehandhabt werden muss, dann J = 4 + 2 + 2 = 8 Pakete (160 ms)und k = 5 Bits (da 2·5 + 1 < 2^5). Der Komprimierer sendet die 5 LSBs von p_TS_aktuell an den Dekomprimierer (351 = 101011111, so ist der kodierte TS-Wert = 11111).
Wenn der Dekomprimierer diesen Wert empfängt, so versucht er zuerst den Zeitstempel zu schätzen durch das Berechnen der Zeitdifferenz zwischen der letzten errichteten Referenz und dem aktuellen Paket.
T_aktuell – T_ref, wobei T_ref der Wert der Wanduhrzeit ist, zu der die Referenzkopfabschnitte durch den Dekomprimierer empfangen wurden.
Dieser Wert wird zu p_TS_ref addiert, dem paketierten RTP TS des Referenzkopfabschnitts, um die Schätzung zu erhalten.
Man nehme an, dass am Dekomprimierer das Paket #3 als Referenz verwendet wird:

– T_aktuell = 359
– T_ref = 7
– p_TS_ref = 4

T_aktuell – T_ref = 359 – 7 = 352

p_TS_aktuell (Schätzung) = 352 + 4 = 356

Der Dekomprimierer sucht nach den am dichtesten an 356 liegenden Wert, der in diesem Fall LSBs = 11111 aufweist. Der Wert in diesem Fall ist 351, der ursprüngliche p_TS.
Wenn stattdessen an den Komprimierer der Zeitstempelsprung als einfach die Differenz in den Zeitstempeln aufeinander folgender Pakete zu senden ist, würde dieser Wert sein: p_TS_aktuell – p_TS_ref = 351 – 4 = 347 = 101011011
So würden über das Doppelte an Bits für ein Stilleintervall von 347 (20 ms) = 6,94 Sekunden gesendet.
Durch die Echtzeitanforderungen an den grundsätzlichen Dialog wird erwartet, dass die kumulative Schwankung bei normalem Betrieb höchstens einige Male des T-Sprungs für Sprache beträgt. Aus diesem Grund werden die FO Nutzdatenformate im Abschnitt 4.3 optimiert (in Ausdrucken der Darstellung verschiedener k-Längen kodierter TS-Werte) für den Fall von k = 4 (handhabt bis zu 16 Diskrepanzen im Zeitstempel). Die verbleibenden Formate erlauben es, einen breiten Bereich von Schwankungszuständen (außerhalb gerade der Sprache) ebenso handzuhaben.
Dieser Internet-Entwurf läuft am 17. März 2001 ab.

Claims

Verfahren zum Komprimieren eines Echtzeitprotokoll-, RTP, -Paketdatenstroms, welcher an einer Komprimierungseinrichtung eintrifft, umfassend: Erhalten eines Musters an der Komprimierungseinrichtung, wobei das Muster eine Zeitstempel-, TS, -Funktion, eine Markierungs-Bit-, M-bit, Funktion, einen Quotienten und eine TS-Schrittgröße umfasst; Sicherstellen, dass eine Dekomprimierungseinrichtung mit der Komprimierungseinrichtung gemäß dem Muster synchronisiert ist, wobei der Schritt des Sicherstellens ein Senden des Musters an die Dekomprimierungseinrichtung umfasst; und Senden eines komprimierten Pakets gemäß dem Muster, wobei das Verfahren dadurch gekennzeichnet ist, dass das Erhalten des Musters umfasst, die TS-Funktion als eine Treppenfunktion der Paketsequenznummer, SN, auszudrücken, wobei die Treppenfunktion mindestens eine Treppenstufe aufweist.
Verfahren zum Komprimieren nach Anspruch 1, wobei das Muster eine M-bit-Funktion umfasst, wobei das M-bit für ein letztes Paket der Treppenstufe gesetzt wird.
Verfahren zum Komprimieren nach Anspruch 2, wobei das M-bit nur für das letzte Paket der Treppenstufe gesetzt wird.
Verfahren nach Anspruch 3, wobei der Schritt des Sicherstellens weiter ein Empfangen einer Angabe umfasst, welche ein Markierungsbit gesetzt hat.
Verfahren nach Anspruch 3, wobei der Schritt des Sicherstellens weiter umfasst: Empfangen einer ersten Bestätigung; und Empfangen einer zweiten Bestätigung.
Verfahren nach Anspruch 3, wobei der Schritt des Sicherstellens weiter umfasst, eine Mustererkennung von mindestens zwei Paketen auszuführen.
Verfahren nach Anspruch 6, wobei der Schritt der Mustererkennung umfasst, die mindestens zwei Pakete zu bestätigen.
Verfahren nach Anspruch 6, wobei die mindestens zwei Pakete ein erstes Paket und ein zweites Paket umfassen und die Schritte vor der Mustererkennung umfassen: Empfangen einer ersten Bestätigung mit mindestens dem ersten Paket; und Empfangen einer zweiten Bestätigung mit mindestens dem zweiten Paket.
Verfahren nach Anspruch 3, wobei der RTP-Paketdatenstrom ein. erstes Paket umfasst, welches eine erste Sequenznummer und ein erstes M-bit aufweist, wobei der Datenstrom ein zweites Paket umfasst, welches eine zweite Sequenznummer und ein zweites M-bit aufweist, wobei das Verfahren weiter umfasst: Erhalten des ersten Pakets und des zweiten Pakets; und Erkennen, dass die zweite Sequenznummer um eins größer als die erste Sequenznummer ist, und dass das erste M-bit und das zweite M-bit gesetzt sind.
Verfahren zum Komprimieren nach Anspruch 3, wobei der Schritt des Sendens des Musters weiter umfasst, explizit das Muster von der Komprimierungseinrichtung an die Dekomprimierungseinrichtung zu senden.
Komprimierungseinrichtung zum Komprimieren eines Echtzeitprotokoll-, RTP Paketdatenstroms, umfassend: Mittel zum Erhalten eines Musters an der Komprimierungseinrichtung, wobei das Muster eine Zeitstempel-, TS, -Funktion, eine Markierungsbit, M-bit, -Funktion, einen Quotienten und eine TS-Schrittgröße umfasst; Mittel zum Sicherstellen, dass eine Dekomprimierungseinrichtung mit der Komprimierungseinrichtung gemäß dem Muster synchronisiert ist, wobei die Mittel zum Sicherstellen Mittel umfassen, um das Muster an die Dekomprimierungseinheit zu senden; und Mittel zum Senden eines komprimierten Pakets gemäß dem Muster; wobei die Komprimierungseinrichtung dadurch gekennzeichnet ist, dass die Mittel zum Erhalten des Musters angepasst sind, um die TS-Funktion als eine Treppenfunktion der Paketsequenznummer SN auszudrücken, wobei die Treppenfunktion mindestens eine Treppenstufe aufweist.
Komprimierungseinrichtung zum Komprimieren nach Anspruch 11, wobei das Muster eine M-bit-Funktion umfasst, wobei das M-bit für ein letztes Paket der Treppenstufe gesetzt ist.
Komprimierungseinrichtung zum Komprimieren nach Anspruch 12, wobei das M-bit nur für das letzte Paket der Treppenstufe gesetzt ist.
Komprimierungseinrichtung nach Anspruch 13, wobei das Mittel zum Sicherstellen weiter ein Mittel zum Empfangen einer Angabe mit einem gesetzten Markierungs-bit umfasst.
Komprimierungseinrichtung nach Anspruch 13, wobei das Mittel zum Sicherstellen weiter umfasst: ein Mittel zum Empfangen einer ersten Bestätigung; und ein Mittel zum Empfangen einer zweiten Bestätigung.
Komprimierungseinrichtung nach Anspruch 13, wobei das Mittel. zum Sicherstellen weiter ein Mittel zur Mustererkennung von mindestens zwei Paketen umfasst.
Komprimierungseinrichtung nach Anspruch 16, wobei das Mittel zur Mustererkennung ein Mittel zum Bestätigen der mindestens zwei Pakete umfasst.
Komprimierungseinrichtung nach Anspruch 16, wobei die mindestens zwei Pakete ein erstes Paket und ein zweites Paket umfassen, weiter umfassend: ein Mittel zum Empfangen einer ersten Bestätigung mit mindestens dem ersten Paket; und ein Mittel zum Empfangen einer zweiten Bestätigung mit mindestens dem zweiten Paket.
Komprimierungseinrichtung nach Anspruch 13, wobei der RTP-Paketdatenstrom ein erstes Paket umfasst, welches eine erste Sequenznummer und ein erstes M-bit aufweist, wobei der Datenstrom ein zweites Paket umfasst, welches eine zweite Sequenznummer und ein zweites M-bit aufweist, wobei die Komprimierungseinrichtung weiter umfasst: ein Mittel zum Erhalten des ersten Pakets und des zweiten Pakets; und ein Mittel zum Erkennen, dass die zweite Sequenznummer um eins größer als die erste Sequenznummer ist und dass das erste M-bit und das zweite M-bit gesetzt sind.
Komprimierungseinrichtung zum Komprimieren nach Anspruch 13, wobei das Mittel zum Senden des Musters weiter ein Mittel umfasst, um explizit das Muster von der Komprimierungseinrichtung an die Dekomprimierungseinrichtung zu senden.