RFC 3095
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
5. The protocol
5.1. Data structures
The ROHC protocol is based on a number of parameters that form part of the negotiated channel state and the per-context state. This section describes some of this state information in an abstract way. Implementations can use a different structure for and representation of this state. In particular, negotiation protocols that set up the per-channel state need to establish the information that constitutes the negotiated channel state, but it is not necessary to exchange it in the form described here.5.1.1. Per-channel parameters
MAX_CID: Nonnegative integer; highest context ID number to be used by the compressor (note that this parameter is not coupled to, but in effect further constrained by, LARGE_CIDS).
LARGE_CIDS: Boolean; if false, the short CID representation (0 bytes or 1 prefix byte, covering CID 0 to 15) is used; if true, the embedded CID representation (1 or 2 embedded CID bytes covering CID 0 to 16383) is used. PROFILES: Set of nonnegative integers, each integer indicating a profile supported by the decompressor. The compressor MUST NOT compress using a profile not in PROFILES. FEEDBACK_FOR: Optional reference to a channel in the reverse direction. If provided, this parameter indicates which channel any feedback sent on this channel refers to (see 5.7.6.1). MRRU: Maximum reconstructed reception unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see 5.2.5). Note that this size includes the CRC. If MRRU is negotiated to be 0, no segment headers are allowed on the channel.5.1.2. Per-context parameters, profiles
Per-context parameters are established with IR headers (see section 5.2.3). An IR header contains a profile identifier, which determines how the rest of the header is to be interpreted. Note that the profile parameter determines the syntax and semantics of the packet type identifiers and packet types used in conjunction with a specific context. This document describes profiles 0x0000, 0x0001, 0x0002, and 0x0003; further profiles may be defined when ROHC is extended in the future. Profile 0x0000 is for sending uncompressed IP packets. See section 5.10. Profile 0x0001 is for RTP/UDP/IP compression, see sections 5.3 through 5.9. Profile 0x0002 is for UDP/IP compression, i.e., compression of the first 12 octets of the UDP payload is not attempted. See section 5.11. Profile 0x0003 is for ESP/IP compression, i.e., compression of the header chain up to and including the first ESP header, but not subsequent subheaders. See section 5.12. Initially, all contexts are in no context state, i.e., all packets referencing this context except IR packets are discarded. If defined by a "ROHC over X" document, per-channel negotiation can be used to pre-establish state information for a context (e.g., negotiating
profile 0x0000 for CID 15). Such state information can also be marked read-only in the negotiation, which would cause the decompressor to discard any IR packet attempting to modify it.5.1.3. Contexts and context identifiers
Associated with each compressed flow is a context, which is the state compressor and decompressor maintain in order to correctly compress or decompress the headers of the packet stream. Contexts are identified by a context identifier, CID, which is sent along with compressed headers and feedback information. The CID space is distinct for each channel, i.e., CID 3 over channel A and CID 3 over channel B do not refer to the same context, even if the endpoints of A and B are the same nodes. In particular, CIDs for any pairs of forward and reverse channels are not related (forward and reverse channels need not even have CID spaces of the same size). Context information is conceptually kept in a table. The context table is indexed using the CID which is sent along with compressed headers and feedback information. The CID space can be negotiated to be either small, which means that CIDs can take the values 0 through 15, or large, which means that CIDs take values between 0 and 2^14 - 1 = 16383. Whether the CID space is large or small is negotiated no later than when a channel is established. A small CID with the value 0 is represented using zero bits. A small CID with a value from 1 to 15 is represented by a four-bit field in place of a packet type field (Add-CID) plus four more bits. A large CID is represented using the encoding scheme of section 4.5.6, limited to two octets.5.2. ROHC packets and packet types
The packet type indication scheme for ROHC has been designed under the following constraints: a) it must be possible to use only a limited number of packet sizes; b) it must be possible to send feedback information in separate ROHC packets as well as piggybacked on forward packets; c) it is desirable to allow elimination of the CID for one packet stream when few packet streams share a channel; d) it is anticipated that some packets with large headers may be larger than the MTU of very constrained lower layers.
These constraints have led to a design which includes
- optional padding,
- a feedback packet type,
- an optional Add-CID octet which provides 4 bits of CID, and
- a simple segmentation and reassembly mechanism.
A ROHC packet has the following general format (in the diagram,
colons ":" indicate that the part is optional):
--- --- --- --- --- --- --- ---
: Padding : variable length
--- --- --- --- --- --- --- ---
: Feedback : 0 or more feedback elements
--- --- --- --- --- --- --- ---
: Header : variable, with CID information
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---
Padding is any number (zero or more) of padding octets. Either of
Feedback or Header must be present.
Feedback elements always start with a packet type indication.
Feedback elements carry internal CID information. Feedback is
described in section 5.2.2.
Header is either a profile-specific header or an IR or IR-DYN header
(see sections 5.2.3 and 5.2.4). Header either
1) does not carry any CID information (indicating CID zero), or
2) includes one Add-CID Octet (see below), or
3) contains embedded CID information of length one or two octets.
Alternatives 1) and 2) apply only to compressed headers in channels
where the CID space is small. Alternative 3) applies only to
compressed headers in channels where the CID space is large.
Padding Octet
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
Add-CID Octet
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
Note: The Padding Octet looks like an Add-CID octet for CID 0.
Header either starts with a packet type indication or has a packet
type indication immediately following an Add-CID Octet. All Header
packet types have the following general format (in the diagram,
slashes "/" indicate variable length):
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if (CID 1-15) and (small CIDs)
+---+--- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+---+--- ---+---+---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if (large CIDs)
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
The large CID, if present, is encoded according to section 4.5.6.
5.2.1. ROHC feedback
Feedback carries information from decompressor to compressor. The
following principal kinds of feedback are supported. In addition to
the kind of feedback, other information may be included in profile-
specific feedback information.
ACK : Acknowledges successful decompression of a packet,
which means that the context is up-to-date with a high
probability.
NACK : Indicates that the dynamic context of the
decompressor is out of sync. Generated when several
successive packets have failed to be decompressed
correctly.
STATIC-NACK : Indicates that the static context of the decompressor
is not valid or has not been established.
It is anticipated that feedback to the compressor can be realized in
many ways, depending on the properties of the particular lower layer.
The exact details of how feedback is realized is to be specified in a
"ROHC over X" document, for each lower layer X in question. For
example, feedback might be realized using
1) lower-layer specific mechanisms
2) a dedicated feedback-only channel, realized for example by the
lower layer providing a way to indicate that a packet is a
feedback packet
3) a dedicated feedback-only channel, where the timing of the
feedback provides information about which compressed packet caused
the feedback
4) interspersing of feedback packets among normal compressed packets
going in the same direction as the feedback (lower layers do not
indicate feedback)
5) piggybacking of feedback information in compressed packets going
in the same direction as the feedback (this technique may reduce
the per-feedback overhead)
6) interspersing and piggybacking on the same channel, i.e., both 4)
and 5).
Alternatives 1-3 do not place any particular requirements on the ROHC
packet type scheme. Alternatives 4-6 do, however. The ROHC packet
type scheme has been designed to allow alternatives 4-6 (these may be
used for example over PPP):
a) The ROHC scheme provides a feedback packet type. The packet type
is able to carry variable-length feedback information.
b) The feedback information sent on a particular channel is passed
to, and interpreted by, the compressor associated with feedback on
that channel. Thus, the feedback information must contain CID
information if the associated compressor can use more than one
context. The ROHC feedback scheme requires that a channel carries
feedback to at most one compressor. How a compressor is
associated with feedback on a particular channel needs to be
defined in a "ROHC over X" document.
c) The ROHC feedback information format is octet-aligned, i.e.,
starts at an octet boundary, to allow using the format over a
dedicated feedback channel, 2).
d) To allow piggybacking, 5), it is possible to deduce the length of
feedback information by examining the first few octets of the
feedback. This allows the decompressor to pass piggybacked
feedback information to the associated same-side compressor
without understanding its format. The length information
decouples the decompressor from the compressor in the sense that
the decompressor can process the compressed header immediately
without waiting for the compressor to hand it back after parsing
the feedback information.
5.2.2. ROHC feedback format
Feedback sent on a ROHC channel consists of one or more concatenated
feedback elements, where each feedback element has the following
format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type octet
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
/ feedback data / variable length
+---+---+---+---+---+---+---+---+
Code: 0 indicates that a Size octet is present.
1-7 indicates the size of the feedback data field in
octets.
Size: Optional octet indicating the size of the feedback data
field in octets.
feedback data: Profile-specific feedback information. Includes
CID information.
The total size of the feedback data field is determinable upon
reception by the decompressor, by inspection of the Code field and
possibly the Size field. This explicit length information allows
piggybacking and also sending more than one feedback element in a
packet.
When the decompressor has determined the size of the feedback data
field, it removes the feedback type octet and the Size field (if
present) and hands the rest to the same-side associated compressor
together with an indication of the size. The feedback data received
by the compressor has the following structure (feedback sent on a
dedicated feedback channel MAY also use this format):
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (4.5.6 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ feedback /
+---+---+---+---+---+---+---+---+
The large CID, if present, is encoded according to section 4.5.6.
CID information in feedback data indicates the CID of the packet
stream for which feedback is sent. Note that the LARGE_CIDS
parameter that controls whether a large CID is present is taken from
the channel state of the receiving compressor's channel, NOT from
that of the channel carrying the feedback.
It is REQUIRED that the feedback field have either of the following
two formats:
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used. Otherwise unparseable.)
The compressor can use the following logic to parse the feedback
field.
1) If for large CIDs, the feedback will always start with a CID
encoded according to section 4.5.6. If the first bit is 0, the
CID uses one octet. If the first bit is 1, the CID uses two
octets.
2) If for small CIDs, and the size is one octet, the feedback is a
FEEDBACK-1.
3) If for small CIDs, and the size is larger than one octet, and the
feedback starts with the two bits 11, the feedback starts with an
Add-CID octet. If the size is 2, it is followed by FEEDBACK-1.
If the size is larger than 2, the Add-CID is followed by
FEEDBACK-2.
4) Otherwise, there is no Add-CID octet, and the feedback starts with
a FEEDBACK-2.
5.2.3. ROHC IR packet type
The IR header associates a CID with a profile, and typically also
initializes the context. It can typically also refresh (parts of)
the context. It has the following general format.
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
x: Profile specific information. Interpreted according to the
profile indicated in the Profile field.
Profile: The profile to be associated with the CID. In the IR
packet, the profile identifier is abbreviated to the 8 least
significant bits. It selects the highest-number profile in the
channel state parameter PROFILES that matches the 8 LSBs given.
CRC: 8-bit CRC computed using the polynomial of section 5.9.1. Its
coverage is profile-dependent, but it MUST cover at least the
initial part of the packet ending with the Profile field. Any
information which initializes the context of the decompressor
should be protected by the CRC.
Profile specific information: The contents of this part of the IR
packet are defined by the individual profiles. Interpreted
according to the profile indicated in the Profile field.
5.2.4. ROHC IR-DYN packet type
In contrast to the IR header, the IR-DYN header can never initialize
an uninitialized context. However, it can redefine what profile is
associated with a context, see for example 5.11 (ROHC UDP) and 5.12
(ROHC ESP). Thus the type needs to be reserved at the framework
level. The IR-DYN header typically also initializes or refreshes
parts of a context, typically the dynamic part. It has the following
general format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
Profile: The profile to be associated with the CID. This is
abbreviated in the same way as with IR packets.
CRC: 8-bit CRC computed using the polynomial of section 5.9.1.
Its coverage is profile-dependent, but it MUST cover at least
the initial part of the packet ending with the Profile field.
Any information which initializes the context of the
decompressor should be protected by the CRC.
Profile specific information: This part of the IR packet is
defined by individual profiles. It is interpreted according
to the profile indicated in the Profile field.
5.2.5. ROHC segmentation
Some link layers may provide a much more efficient service if the set
of different packet sizes to be transported is kept small. For such
link layers, these sizes will normally be chosen to transport
frequently occurring packets efficiently, with less frequently
occurring packets possibly adapted to the next larger size by the
addition of padding. The link layer may, however, be limited in the
size of packets it can offer in this efficient mode, or it may be
desirable to request only a limited largest size. To accommodate the
occasional packet that is larger than that largest size negotiated,
ROHC defines a simple segmentation protocol.
5.2.5.1. Segmentation usage considerations
The segmentation protocol defined in ROHC is not particularly
efficient. It is not intended to replace link layer segmentation
functions; these SHOULD be used whenever available and efficient for
the task at hand.
ROHC segmentation should only be used for occasional packets with
sizes larger than what is efficient to accommodate, e.g., due to
exceptionally large ROHC headers. The segmentation scheme was
designed to reduce packet size variations that may occur due to
outliers in the header size distribution. In other cases,
segmentation should be done at lower layers. The segmentation scheme
should only be used for packet sizes that are larger than the maximum
size in the allowed set of sizes from the lower layers.
In summary, ROHC segmentation should be used with a relatively low
frequency in the packet flow. If this cannot be ensured,
segmentation should be performed at lower layers.
5.2.5.2. Segmentation protocol
Segment Packet 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 1 | F | +---+---+---+---+---+---+---+---+ / Segment / variable length +---+---+---+---+---+---+---+---+ F: Final bit. If set, it indicates that this is the last segment of a reconstructed unit. The segment header may be preceded by padding octets and/or feedback. It never carries a CID. All segment header packets for one reconstructed unit have to be sent consecutively on a channel, i.e., any non-segment-header packet following a nonfinal segment header aborts the reassembly of the current reconstructed unit and causes the decompressor to discard the nonfinal segments received on this channel so far. When a final segment header is received, the decompressor reassembles the segment carried in this packet and any nonfinal segments that immediately preceded it into a single reconstructed unit, in the order they were received. The reconstructed unit has the format: Reconstructed Unit 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | / Reconstructed ROHC packet / variable length | | +---+---+---+---+---+---+---+---+ / CRC / 4 octets +---+---+---+---+---+---+---+---+ The CRC is used by the decompressor to validate the reconstructed unit. It uses the FCS-32 algorithm with the following generator polynomial: x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 [HDLC]. If the reconstructed unit is 4 octets or less, or if the CRC fails, or if it is larger than the channel parameter MRRU (see 5.1.1), the reconstructed unit MUST be discarded by the decompressor.
If the CRC succeeds, the reconstructed ROHC packet is interpreted as a ROHC Header, optionally followed by a payload. Note that this means that there can be no padding and no feedback in the reconstructed unit, and that the CID is derived from the initial octets of the reconstructed unit. (It should be noted that the ROHC segmentation protocol was inspired by SEAL by Steve Deering et al., which later became ATM AAL5. The same arguments for not having sequence numbers in the segments but instead providing a strong CRC in the reconstructed unit apply here as well. Note that, as a result of this protocol, there is no way in ROHC to make any use of a segment that has residual bit errors.)5.2.6. ROHC initial decompressor processing
The following packet types are reserved at the framework level in the ROHC scheme: 1110: Padding or Add-CID octet 11110: Feedback 11111000: IR-DYN packet 1111110: IR packet 1111111: Segment Other packet types can be used at will by individual profiles. The following steps is an outline of initial decompressor processing which upon reception of a ROHC packet can determine its contents. 1) If the first octet is a Padding Octet (11100000), strip away all initial Padding Octets and goto next step. 2) If the first remaining octet starts with 1110, it is an Add-CID octet: remember the Add-CID octet; remove the octet. 3) If the first remaining octet starts with 11110, and an Add-CID octet was found in step 2), an error has occurred; the header MUST be discarded without further action. 4) If the first remaining octet starts with 11110, and an Add-CID octet was not found in step 2), this is feedback: find the size of the feedback data, call it s; remove the feedback type octet;
remove the Size octet if Code is 0;
send feedback data of length s to the same-side associated
compressor;
if packet exhausted, stop; otherwise goto 2).
5) If the first remaining octet starts with 1111111, this is a
segment:
attempt reconstruction using the segmentation protocol
(5.2.5). If a reconstructed packet is not produced, this
finishes the processing of the original packet. If a
reconstructed packet is produced, it is fed into step 1)
above. Padding, segments, and feedback are not allowed in
reconstructed packets, so when processing them, steps 1),
4), and 5) are modified so that the packet is discarded
without further action when their conditions match.
6) Here, it is known that the rest is forward information (unless the
header is damaged).
7) If the forward traffic uses small CIDs, there is no large CID in
the packet. If an Add-CID immediately preceded the packet type
(step 2), it has the CID of the Add-CID; otherwise it has CID 0.
8) If the forward traffic uses large CIDs, the CID starts with the
second remaining octet. If the first bit(s) of that octet are not
0 or 10, the packet MUST be discarded without further action. If
an Add-CID octet immediately preceded the packet type (step 2),
the packet MUST be discarded without further action.
9) Use the CID to find the context.
10) If the packet type is IR, the profile indicated in the IR packet
determines how it is to be processed. If the CRC fails to verify
the packet, it MUST be discarded. If a profile is indicated in
the context, the logic of that profile determines what, if any,
feedback is to be sent. If no profile is noted in the context,
no further action is taken.
11) If the packet type is IR-DYN, the profile indicated in the IR-DYN
packet determines how it is to be processed.
a) If the CRC fails to verify the packet, it MUST be discarded.
If a profile is indicated in the context, the logic of that
profile determines what, if any, feedback is to be sent. If no
profile is noted in the context, no further action is taken.
b) If the context has not been initialized by an IR packet, the
packet MUST be discarded. The logic of the profile indicated
in the IR-DYN header (if verified by the CRC), determines what,
if any, feedback is to be sent.
12) Otherwise, the profile noted in the context determines how the
rest of the packet is to be processed. If the context has not
been initialized by an IR packet, the packet MUST be discarded
without further action.
The procedure for finding the size of the feedback data is as
follows:
Examine the three bits which immediately follow the feedback packet
type. When these bits are
1-7, the size of the feedback data is given by the bits;
0, a Size octet, which explicitly gives the size of the
feedback data, is present after the feedback type octet.
5.2.7. ROHC RTP packet formats from compressor to decompressor
ROHC RTP uses three packet types to identify compressed headers, and
two for initialization/refresh. The format of a compressed packet
can depend on the mode. Therefore a naming scheme of the form
<modes format is used in>-<packet type number>-<some property>
is used to uniquely identify the format when necessary, e.g., UOR-2,
R-1. For exact formats of the packet types, see section 5.7.
Packet type zero: R-0, R-0-CRC, UO-0.
This, the minimal, packet type is used when parameters of all SN-
functions are known by the decompressor, and the header to be
compressed adheres to these functions. Thus, only the W-LSB
encoded RTP SN needs to be communicated.
R-mode: Only if a CRC is present (packet type R-0-CRC) may the
header be used as a reference for subsequent decompression.
U-mode and O-mode: A small CRC is present in the UO-0 packet.
Packet type 1: R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS.
This packet type is used when the number of bits needed for the SN
exceeds those available in packet type zero, or when the
parameters of the SN-functions for RTP TS or IP-ID change.
R-mode: R-1-* packets are not used as references for subsequent
decompression. Values for other fields than the RTP TS or IP-ID
can be communicated using an extension, but they do not update the
context.
U-mode and O-mode: Only the values of RTP SN, RTP TS and IP-ID can
be used as references for future compression. Nonupdating values
can be provided for other fields using an extension (UO-1-ID).
Packet type 2: UOR-2, UOR-2-ID, UOR-2-TS
This packet type can be used to change the parameters of any SN-
function, except those for most static fields. Headers of packets
transferred using packet type 2 can be used as references for
subsequent decompression.
Packet type: IR
This packet type communicates the static part of the context,
i.e., the value of the constant SN-functions. It can optionally
also communicate the dynamic part of the context, i.e., the
parameters of the nonconstant SN-functions.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context,
i.e., the parameters of nonconstant SN-functions.
5.2.8. Parameters needed for mode transition in ROHC RTP
The packet types IR (with dynamic information), IR-DYN, and UOR-2 are
common for all modes. They can carry a mode parameter which can take
the values U = Unidirectional, O = Bidirectional Optimistic, and R =
Bidirectional Reliable.
Feedback of types ACK, NACK, and STATIC-NACK carry sequence numbers,
and feedback packets can also carry a mode parameter indicating the
desired compression mode: U, O, or R.
As a shorthand, the notation PACKET(mode) is used to indicate which
mode value a packet carries. For example, an ACK with mode parameter
R is written ACK(R), and an UOR-2 with mode parameter O is written
UOR-2(O).
5.3. Operation in Unidirectional mode
5.3.1. Compressor states and logic (U-mode)
Below is the state machine for the compressor in Unidirectional mode. Details of the transitions between states and compression logic are given subsequent to the figure. Optimistic approach +------>------>------>------>------>------>------>------>------+ | | | Optimistic approach Optimistic approach | | +------>------>------+ +------>------>------+ | | | | | | | | | v | v v +----------+ +----------+ +----------+ | IR State | | FO State | | SO State | +----------+ +----------+ +----------+ ^ ^ | ^ | | | | Timeout | | Timeout / Update | | | +------<------<------+ +------<------<------+ | | | | Timeout | +------<------<------<------<------<------<------<------<------+5.3.1.1. State transition logic (U-mode)
The transition logic for compression states in Unidirectional mode is based on three principles: the optimistic approach principle, timeouts, and the need for updates.5.3.1.1.1. Optimistic approach, upwards transition
Transition to a higher compression state in Unidirectional mode is carried out according to the optimistic approach principle. This means that the compressor transits to a higher compression state when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state. When the compressor is in the IR state, it will stay there until it assumes that the decompressor has correctly received the static context information. For transition from the FO to the SO state, the compressor should be confident that the decompressor has all parameters needed to decompress according to a fixed pattern.
The compressor normally obtains its confidence about decompressor status by sending several packets with the same information according to the lower compression state. If the decompressor receives any of these packets, it will be in sync with the compressor. The number of consecutive packets to send for confidence is not defined in this document.5.3.1.1.2. Timeouts, downward transition
When the optimistic approach is taken as described above, there will always be a possibility of failure since the decompressor may not have received sufficient information for correct decompression. Therefore, the compressor MUST periodically transit to lower compression states. Periodic transition to the IR state SHOULD be carried out less often than transition to the FO state. Two different timeouts SHOULD therefore be used for these transitions. For an example of how to implement periodic refreshes, see [IPHC] chapters 3.3.1-3.3.2.5.3.1.1.3. Need for updates, downward transition
In addition to the downward state transitions carried out due to periodic timeouts, the compressor must also immediately transit back to the FO state when the header to be compressed does not conform to the established pattern.5.3.1.2. Compression logic and packets used (U-mode)
The compressor chooses the smallest possible packet format that can communicate the desired changes, and has the required number of bits for W-LSB encoded values.5.3.1.3. Feedback in Unidirectional mode
The Unidirectional mode of operation is designed to operate over links where a feedback channel is not available. If a feedback channel is available, however, the decompressor MAY send an acknowledgment of successful decompression with the mode parameter set to U (send an ACK(U)). When the compressor receives such a message, it MAY disable (or increase the interval between) periodic IR refreshes.5.3.2. Decompressor states and logic (U-mode)
Below is the state machine for the decompressor in Unidirectional mode. Details of the transitions between states and decompression logic are given subsequent to the figure.
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+--------------+ +----------------+ +--------------+
| No Context | | Static Context | | Full Context |
+--------------+ +----------------+ +--------------+
^ | ^ |
| k_2 out of n_2 failures | | k_1 out of n_1 failures |
+-----<------<------<-----+ +-----<------<------<-----+
5.3.2.1. State transition logic (U-mode)
Successful decompression will always move the decompressor to the
Full Context state. Repeated failed decompression will force the
decompressor to transit downwards to a lower state. The decompressor
does not attempt to decompress headers at all in the No Context and
Static Context states unless sufficient information is included in
the packet itself.
5.3.2.2. Decompression logic (U-mode)
Decompression in Unidirectional mode is carried out following three
steps which are described in subsequent sections.
5.3.2.2.1. Decide whether decompression is allowed
In Full Context state, decompression may be attempted regardless of
what kind of packet is received. However, for the other states
decompression is not always allowed. In the No Context state only IR
packets, which carry the static information fields, may be
decompressed. Further, when in the Static Context state, only
packets carrying a 7- or 8-bit CRC can be decompressed (i.e., IR,
IR-DYN, or UOR-2 packets). If decompression may not be performed the
packet is discarded, unless the optional delayed decompression
mechanism is used, see section 6.1.
5.3.2.2.2. Reconstruct and verify the header
When reconstructing the header, the decompressor takes the header
information already stored in the context and updates it with the
information received in the current header. (If the reconstructed
header fails the CRC check, these updates MUST be undone.)
The sequence number is reconstructed by replacing the sequence number LSBs in the context with those received in the header. The resulting value is then verified to be within the interpretation interval by comparison with a previously reconstructed reference value v_ref (see section 4.5.1). If it is not within this interval, an adjustment is applied by adding N x interval_size to the reconstructed value so that the result is brought within the interpretation interval. Note that N can be negative. If RTP Timestamp and IP Identification fields are not included in the received header, they are supposed to be calculated from the sequence number. The IP Identifier usually increases by the same delta as the sequence number and the timestamp by the same delta times a fixed value. See chapters 4.5.3 and 4.5.5 for details about how these fields are encoded in compressed headers. When working in Unidirectional mode, all compressed headers carry a CRC which MUST be used to verify decompression.5.3.2.2.3. Actions upon CRC failure
This section is written so that it is applicable to all modes. A mismatch in the CRC can be caused by one or more of: 1. residual bit errors in the current header 2. a damaged context due to residual bit errors in previous headers 3. many consecutive packets being lost between compressor and decompressor (this may cause the LSBs of the SN in compressed packets to be interpreted wrongly, because the decompressor has not moved the interpretation interval for lack of input -- in essence, a kind of context damage). (Cases 2 and 3 do not apply to IR packets; case 3 does not apply to IR-DYN packets.) The 3-bit CRC present in some header formats will eventually detect context damage reliably, since the probability of undetected context damage decreases exponentially with each new header processed. However, residual bit errors in the current header are only detected with good probability, not reliably. When a CRC mismatch is caused by residual bit errors in the current header (case 1 above), the decompressor should stay in its current state to avoid unnecessary loss of subsequent packets. On the other hand, when the mismatch is caused by a damaged context (case 2), the decompressor should attempt to repair the context locally. If the local repair attempt fails, it must move to a lower state to avoid
delivering incorrect headers. When the mismatch is caused by prolonged loss (case 3), the decompressor might attempt additional decompression attempts. Note that case 3 does not occur in R-mode. The following actions MUST be taken when a CRC check fails: First, attempt to determine whether SN LSB wraparound (case 3) is likely, and if so, attempt a correction. For this, the algorithm of section 5.3.2.2.4 MAY be used. If another algorithm is used, it MUST have at least as high a rate of correct repairs as the one in 5.3.2.2.4. (This step is not applicable to R-mode.) Second, if the previous step did not attempt a correction, a repair should be attempted under the assumption that the reference SN has been incorrectly updated. For this, the algorithm of section 5.3.2.2.5 MAY be used. If another algorithm is used, it MUST have at least as high a rate of correct repairs as the one in 5.3.2.2.5. (This step is not applicable to R-mode.) If both the above steps fail, additional decompression attempts SHOULD NOT be made. There are two possible reasons for the CRC failure: case 1 or unrecoverable context damage. It is impossible to know for certain which of these is the actual cause. The following rules are to be used: a. When CRC checks fail only occasionally, assume residual errors in the current header and simply discard the packet. NACKs SHOULD NOT be sent at this time. b. In the Full Context state: When the CRC check of k_1 out of the last n_1 decompressed packets have failed, context damage SHOULD be assumed and a NACK SHOULD be sent in O- and R-mode. The decompressor moves to the Static Context state and discards all packets until an update (IR, IR-DYN, UOR-2) which passes the CRC check is received. c. In the Static Context state: When the CRC check of k_2 out of the last n_2 updates (IR, IR-DYN, UOR-2) have failed, static context damage SHOULD be assumed and a STATIC-NACK is sent in O- and R- mode. The decompressor moves to the No Context state. d. In the No Context state: The decompressor discards all packets until a static update (IR) which passes the CRC check is received. (In O-mode and R-mode, feedback is sent according to sections 5.4.2.2 and 5.5.2.2, respectively.)
Note that appropriate values for k_1, n_1, k_2, and n_2, are related to the residual error rate of the link. When the residual error rate is close to zero, k_1 = n_1 = k_2 = n_2 = 1 may be appropriate.5.3.2.2.4. Correction of SN LSB wraparound
When many consecutive packets are lost there will be a risk of sequence number LSB wraparound, i.e., the SN LSBs being interpreted wrongly because the interpretation interval has not moved for lack of input. The decompressor might be able to detect this situation and avoid context damage by using a local clock. The following algorithm MAY be used: a. The decompressor notes the arrival time, a(i), of each incoming packet i. Arrival times of packets where decompression fails are discarded. b. When decompression fails, the decompressor computes INTERVAL = a(i) - a(i - 1), i.e., the time elapsed between the arrival of the previous, correctly decompressed packet and the current packet. c. If wraparound has occurred, INTERVAL will correspond to at least 2^k inter-packet times, where k is the number of SN bits in the current header. On the basis of an estimate of the packet inter- arrival time, obtained for example using a moving average of arrival times, TS_STRIDE, or TS_TIME, the decompressor judges if INTERVAL can correspond to 2^k inter-packet times. d. If INTERVAL is judged to be at least 2^k packet inter-arrival times, the decompressor adds 2^k to the reference SN and attempts to decompress the packet using the new reference SN. e. If this decompression succeeds, the decompressor updates the context but SHOULD NOT deliver the packet to upper layers. The following packet is also decompressed and updates the context if its CRC succeeds, but SHOULD be discarded. If decompression of the third packet using the new context also succeeds, the context repair is deemed successful and this and subsequent decompressed packets are delivered to the upper layers. f. If any of the three decompression attempts in d. and e. fails, the decompressor discards the packets and acts according to rules a) through c) of section 5.3.2.2.3. Using this mechanism, the decompressor may be able to repair the context after excessive loss, at the expense of discarding two packets.
5.3.2.2.5. Repair of incorrect SN updates
The CRC can fail to detect residual errors in the compressed header because of its limited length, i.e., the incorrectly decompressed packet can happen to have the same CRC as the original uncompressed packet. The incorrect decompressed header will then update the context. This can lead to an erroneous reference SN being used in W-LSB decoding, as the reference SN is updated for each successfully decompressed header of certain types. In this situation, the decompressor will detect the incorrect decompression of the following packet with high probability, but it does not know the reason for the failure. The following mechanism allows the decompressor to judge if the context was updated incorrectly by an earlier packet and, if so, to attempt a repair. a. The decompressor maintains two decompressed sequence numbers: the last one (ref 0) and the one before that (ref -1). b. When receiving a compressed header the SN (SN curr1) is decompressed using ref 0 as the reference. The other header fields are decompressed using this decompressed SN curr1. (This is part of the normal decompression procedure prior to any CRC test failures.) c. If the decompressed header generated in b. passes the CRC test, the references are shifted as follows: ref -1 = ref 0 ref 0 = SN curr1. d. If the header generated in b. does not pass the CRC test, and the SN (SN curr2) generated when using ref -1 as the reference is different from SN curr1, an additional decompression attempt is performed based on SN curr2 as the decompressed SN. e. If the decompressed header generated in b. does not pass the CRC test and SN curr2 is the same as SN curr1, an additional decompression attempt is not useful and is not attempted. f. If the decompressed header generated in d. passes the CRC test, ref -1 is not changed while ref 0 is set to SN curr2. g. If the decompressed header generated in d. does not pass the CRC test, the decompressor acts according to rules a) through c) of section 5.3.2.2.3.
The purpose of this algorithm is to repair the context. If the header generated in d. passes the CRC test, the references are updated according to f., but two more headers MUST also be successfully decompressed before the repair is deemed successful. Of the three successful headers, the first two SHOULD be discarded and only the third delivered to upper layers. If decompression of any of the three headers fails, the decompressor MUST discard that header and the previously generated headers, and act according to rules a) through c) of section 5.3.2.2.3.5.3.2.3. Feedback in Unidirectional mode
To improve performance for the Unidirectional mode over a link that does have a feedback channel, the decompressor MAY send an acknowledgment when decompression succeeds. Setting the mode parameter in the ACK packet to U indicates that the compressor is to stay in Unidirectional mode. When receiving an ACK(U), the compressor should reduce the frequency of IR packets since the static information has been correctly received, but it is not required to stop sending IR packets. If IR packets continue to arrive, the decompressor MAY repeat the ACK(U), but it SHOULD NOT repeat the ACK(U) continuously.5.4. Operation in Bidirectional Optimistic mode
5.4.1. Compressor states and logic (O-mode)
Below is the state machine for the compressor in Bidirectional Optimistic mode. The details of each state, state transitions, and compression logic are given subsequent to the figure. Optimistic approach / ACK +------>------>------>------>------>------>------>------>------+ | | | Optimistic appr. / ACK Optimistic appr. /ACK ACK | | +------>------>------+ +------>--- -->-----+ +->--+ | | | | | | | | | v | v | v +----------+ +----------+ +----------+ | IR State | | FO State | | SO State | +----------+ +----------+ +----------+ ^ ^ | ^ | | | | STATIC-NACK | | NACK / Update | | | +------<------<------+ +------<------<------+ | | | | STATIC-NACK | +------<------<------<------<------<------<------<------<------+
5.4.1.1. State transition logic
The transition logic for compression states in Bidirectional Optimistic mode has much in common with the logic of the Unidirectional mode. The optimistic approach principle and transitions occasioned by the need for updates work in the same way as described in chapter 5.3.1. However, in Optimistic mode there are no timeouts. Instead, the Optimistic mode makes use of feedback from decompressor to compressor for transitions in the backward direction and for OPTIONAL improved forward transition.5.4.1.1.1. Negative acknowledgments (NACKs), downward transition
Negative acknowledgments (NACKs), also called context requests, obviate the periodic updates needed in Unidirectional mode. Upon reception of a NACK the compressor transits back to the FO state and sends updates (IR-DYN, UOR-2, or possibly IR) to the decompressor. NACKs carry the SN of the latest packet successfully decompressed, and this information MAY be used by the compressor to determine what fields need to be updated. Similarly, reception of a STATIC-NACK packet makes the compressor transit back to the IR state.5.4.1.1.2. Optional acknowledgments, upwards transition
In addition to NACKs, positive feedback (ACKs) MAY also be used for UOR-2 packets in the Bidirectional Optimistic mode. Upon reception of an ACK for an updating packet, the compressor knows that the decompressor has received the acknowledged packet and the transition to a higher compression state can be carried out immediately. This functionality is optional, so a compressor MUST NOT expect to get such ACKs initially. The compressor MAY use the following algorithm to determine when to expect ACKs for UOR-2 packets. Let an update event be when a sequence of UOR-2 headers are sent to communicate an irregularity in the packet stream. When ACKs have been received for k_3 out of the last n_3 update events, the compressor will expect ACKs. A compressor which expects ACKs will repeat updates (possibly not in every packet) until an ACK is received.5.4.1.2. Compression logic and packets used
The compression logic is the same for the Bidirectional Optimistic mode as for the Unidirectional mode (see section 5.3.1.2).
5.4.2. Decompressor states and logic (O-mode)
The decompression states and the state transition logic are the same as for the Unidirectional case (see section 5.3.2). What differs is the decompression and feedback logic.5.4.2.1. Decompression logic, timer-based timestamp decompression
In Bidirectional mode (or if there is some other way for the compressor to obtain the decompressor's clock resolution and the link's jitter), timer-based timestamp decompression may be used to improve compression efficiency when RTP Timestamp values are proportional to wall-clock time. The mechanisms used are those described in 4.5.4.5.4.2.2. Feedback logic (O-mode)
The feedback logic defines what feedback to send due to different events when operating in the various states. As mentioned above, there are three principal kinds of feedback; ACK, NACK and STATIC- NACK. Further, the logic described below will refer to different kinds of packets that can be received by the decompressor; Initialization and Refresh (IR) packets, IR packets without static information (IR-DYN) and type 2 packets (UOR-2), or type 1 (UO-1) and type 0 packets (UO-0). A type 0 packet carries a packet header compressed according to a fixed pattern, while type 1, 2 and IR-DYN packets are used when this pattern is broken. Below, rules are defined stating which feedback to use when. If the optional feedback is used once, the decompressor is REQUIRED to continue to send optional feedback for the lifetime of the packet stream. State Actions NC: - When an IR packet passes the CRC check, send an ACK(O). - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR packet has failed the CRC check, send a STATIC-NACK(O), subject to the considerations at the beginning of section 5.7.6. SC: - When an IR packet is correctly decompressed, send an ACK(O). - When a type 2 or an IR-DYN packet is correctly decompressed, optionally send an ACK(O). - When a type 0 or 1 packet is received, treat it as a mismatching CRC and use the logic of section 5.3.2.2.3 to decide if a NACK(O) should be sent.
- When decompression of a type 2 packet, an IR-DYN packet or an
IR packet has failed, use the logic of section 5.3.2.2.3 to
decide if a STATIC-NACK(O) should be sent.
FC: - When an IR packet is correctly decompressed, send an ACK(O).
- When a type 2 or an IR-DYN packet is correctly decompressed,
optionally send an ACK(O).
- When a type 0 or 1 packet is correctly decompressed, no
feedback is sent.
- When any packet fails the CRC check, use the logic of
5.3.2.2.3 to decide if a NACK(O) should be sent.
(page 65 continued on part 4)
