: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
Note that the first octet of the IP packet starts with the bit
pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any
reserved packet types. Hence, no bits in addition to the CID are
needed. The profile is reasonably future-proof since problems do not
occur until IP version 14.
5.10.3. States and modes
There are two modes in Profile 0x0000: Unidirectional mode and
Bidirectional mode. In Unidirectional mode, the compressor repeats
the IR packet periodically. In Bidirectional mode, the compressor
never repeats the IR packet. The compressor and decompressor always
start in Unidirectional mode. Whenever feedback is received, the
compressor switches to Bidirectional mode.
The compressor can be in either of two states: the IR state or the
Normal state. It starts in the IR state.
a) IR state: Only IR packets can be sent. After sending a small
number of IR packets (only one when refreshing), the compressor
switches to the Normal state.
b) Normal state: Only Normal packets can be sent. When in
Unidirectional mode, the compressor periodically transits back to
the IR state. The length of the period is implementation
dependent, but should be fairly long. Exponential backoff may be
used.
c) When feedback is received in any state, the compressor switches to
Bidirectional mode.
The decompressor can be in either of two states: NO_CONTEXT or
FULL_CONTEXT. It starts in NO_CONTEXT.
d) When an IR packet is received in the NO_CONTEXT state, the
decompressor first verifies the packet using the CRC. If the
packet is OK, the decompressor 1) moves to the FULL_CONTEXT state,
2) delivers the IP packet to upper layers if present, 3) MAY send
an ACK. If the packet is not OK, it is discarded without further
action.
e) When any other packet is received in the NO_CONTEXT state, it is
discarded without further action.
f) When an IR packet is received in the FULL_CONTEXT state, the
packet is first verified using the CRC. If OK, the decompressor
1) delivers the IP packet to upper layers if present, 2) MAY send
an ACK. If the packet is not OK, no action is taken.
g) When a Normal packet is received in the FULL_CONTEXT state, the
CID information is removed and the IP packet is delivered to upper
layers.
5.10.4. Feedback
The only kind of feedback in Profile 0x0000 is ACKs. Profile 0x0000
MUST NOT be rejected. Profile 0x0000 SHOULD be associated with at
most one CID. ACKs use the FEEDBACK-1 format of section 5.2. The
value of the profile-specific octet in the FEEDBACK-1 ACK is 0
(zero).
5.11. ROHC UDP -- non-RTP UDP/IP compression (Profile 0x0002)
UDP/IP headers do not have a sequence number which is as well-behaved
as the RTP Sequence Number. For UDP/IPv4, there is an IP-ID field
which may be echoed in feedback information, but when no IPv4 header
is present such feedback identification becomes problematic.
Therefore, in the ROHC UDP profile, the compressor generates a 16-bit
sequence number SN which increases by one for each packet received in
the packet stream. This sequence number is thus relatively well-
behaved and can serve as the basis for most mechanisms described for
ROHC RTP. It is called SN or UDP SN below. Unless stated otherwise,
the mechanisms of ROHC RTP are used also for ROHC UDP, with the UDP
SN taking the role of the RTP Sequence Number.
The ROHC UDP profile always uses p = -1 when interpreting the SN,
since there will be no repetitions or reordering of the compressor-
generated SN. The interpretation interval thus always starts with
(ref_SN + 1).
5.11.1. Initialization
The static context for ROHC UDP streams can be initialized in either
of two ways:
1) By using an IR packet as in section 5.7.7.1, where the profile is
two (2) and the static chain ends with the static part of an UDP
packet. At the compressor, UDP SN is initialized to a random
value when the IR packet is sent.
2) By reusing an existing context where the existing static chain
contains the static part of a UDP packet, e.g., the context of a
stream compressed using ROHC RTP (profile 0x0001). This is done
with an IR-DYN packet (section 5.7.7.2) identifying profile
0x0002, where the dynamic chain corresponds to the prefix of the
existing static chain that ends with the UDP header. UDP SN is
initialized to the RTP Sequence Number if the earlier profile was
profile 0x0001, and to a random number otherwise.
For ROHC UDP, the dynamic part of a UDP packet is different from
section 5.7.7.5: a two-octet field containing the UDP SN is added
after the Checksum field. This affects the format of dynamic chains
in IR and IR-DYN packets.
Note: 2) can be used for packet streams which were initially assumed
to be RTP streams, so that compression started with profile 0x0001,
but were later found evidently not to be RTP streams.
5.11.2. States and modes
ROHC UDP uses the same states and modes as ROHC RTP. Mode
transitions and state logic are the same except when explicitly
stated otherwise. Mechanisms dealing with fields in the RTP header
(except the RTP SN) are not used. The decompressed UDP SN is never
included in any header delivered to upper layers. The UDP SN is used
in place of the RTP SN in feedback.
5.11.3. Packet types
The general format of a ROHC UDP packet is the same as for ROHC RTP
(see beginning of section 5.7). Padding and CIDs are the same, as is
the feedback packet type (5.7.6.1) and the feedback. IR and IR-DYN
packets (5.7.7) are changed as described in 5.11.1.
The general format of compressed packets is also the same, but there
are differences in specific formats and extensions as detailed below.
The differences are caused by removal of all RTP specific information
except the RTP SN, which is replaced by the UDP SN.
Unless explicitly stated below, the packet formats are as in sections
5.7.1-6.
R-1
The TS field is replaced by an IP-ID field. The M flag has become
part of IP-ID. The X bit has moved. The formats R-1-ID and R-1-
TS are not used.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | SN |
+===+===+===+===+===+===+===+===+
| X | IP-ID |
+---+---+---+---+---+---+---+---+
UO-1
The TS field is replaced by an IP-ID field. The M flag has become
part of SN. Formats UO-1-ID and UO-1-TS are not used.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 0 | IP-ID |
+===+===+===+===+===+===+===+===+
| SN | CRC |
+---+---+---+---+---+---+---+---+
UOR-2
New format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | SN |
+===+===+===+===+===+===+===+===+
| X | CRC |
+---+---+---+---+---+---+---+---+
5.11.4. Extensions
Extensions are as in 5.7.5, with the following exceptions:
Extension 0:
+---+---+---+---+---+---+---+---+
| 0 0 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
Extension 1:
+---+---+---+---+---+---+---+---+
| 0 1 | SN | IP-ID |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
Extension 2:
+---+---+---+---+---+---+---+---+
| 1 0 | SN | IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID2 |
+---+---+---+---+---+---+---+---+
| IP-ID |
+---+---+---+---+---+---+---+---+
IP-ID2: For outer IP-ID field.
Extension 3 is the same as Extension 3 in section 5.7.5, with the
following exceptions.
1) The initial flag octet has the following format:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 1 | S | Mode | I | ip | ip2 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Mode: Replaces R-TS and Tsc of 5.7.5. Provides mode information
as was earlier done in RTP header flags and fields.
ip2: Replaces rtp bit of 5.7.5. Moved here from the Inner IP
header flags octet.
2) The bit which was the ip2 flag in the Inner IP header flags in
5.7.5 is reserved. It is set to zero when sending and ignored
when receiving.
5.11.5. IP-ID
Treated as in ROHC RTP, but the offset is from UDP SN.
5.11.6. Feedback
Feedback is as for ROHC RTP with the following exceptions:
1) UDP SN replaces RTP SN in feedback.
2) The CLOCK option (5.7.6.6) is not used.
3) The JITTER option (5.7.6.7) is not used.
5.12. ROHC ESP -- ESP/IP compression (Profile 0x0003)
When the ESP header is being used with an encryption algorithm other
than NULL, subheaders after the ESP header are encrypted and cannot
be compressed. Profile 0x0003 is for compression of the chain of
headers up to and including the ESP header in this case. When the
NULL encryption algorithm is being used, other profiles can be used
and could give higher compression rates. See section 5.8.4.3.
This profile is very similar to the ROHC UDP profile. It uses the
ESP sequence number as the basis for compression instead of a
generated number, but is otherwise very similar to ROHC UDP. The
interpretation interval (value of p) for the ESP-based SN is as with
ROHC RTP (profile 0x0001). Apart from this, unless stated explicitly
below, mechanisms and formats are as for ROHC UDP.
5.12.1. Initialization
The static context for ROHC ESP streams can be initialized in either
of two ways:
1) by using an IR packet as in section 5.7.7.1, where the profile is
three (3) and the static chain ends with the static part of an ESP
header.
2) by reusing an existing context, where the existing static chain
contains the static part of an ESP header. This is done with an
IR-DYN packet (section 5.7.7.2) identifying profile 0x0003, where
the dynamic chain corresponds to the prefix of the existing static
chain that ends with the ESP header.
In contrast to ROHC UDP, no extra sequence number is added to the
dynamic part of the ESP header: the ESP sequence number is the only
element.
Note: 2) can be used for streams where compression has been initiated
under the assumption that NULL encryption was being used with ESP.
When it becomes obvious that an encryption algorithm other than NULL
is being used, the compressor may send an IR-DYN according to 2) to
switch to profile 0x0003 without having to send an IR packet.
5.12.2. Packet types
The packet types for ROHC ESP are the same as for ROHC UDP, except
that the ESP sequence number is used instead of the generated
sequence number of ROHC UDP. The ESP header is not part of any
compressed list in ROHC ESP.
6. Implementation issues
This document specifies mechanisms for the protocol and leaves many
details on the use of these mechanisms to the implementers. This
chapter is aimed to give guidelines, ideas and suggestions for
implementing the scheme.
6.1. Reverse decompression
This section describes an OPTIONAL decompressor operation to reduce
the number of packets discarded due to an invalid context.
Once a context becomes invalid (e.g., when more consecutive packet
losses than expected have occurred), subsequent compressed packets
cannot immediately be decompressed correctly. Reverse decompression
aims at decompressing such packets later instead of discarding them,
by storing them until the context has been updated and validated and
then attempting decompression.
Let the sequence of stored packets be i, i + 1, ..., i + k, where i
is the first packet and i + k is the last packet before the context
was updated. The decompressor will attempt to recover the stored
packets in reverse order, i.e., starting with i + k, and working back
toward i. When a stored packet has been reconstructed, its
correctness is verified using its CRC. Packets not carrying a CRC
must not be delivered to upper layers. Packets where the CRC
succeeds are delivered to upper layers in their original order, i.e.,
i, i + 1, ..., i + k.
Note that this reverse decompression introduces buffering while
waiting for the context to be validated and thereby introduces
additional delay. Thus, it should be used only when some amount of
delay is acceptable. For example, for video packets belonging to the
same video frame, the delay in packet arrivals does not cause
presentation time delay. Delay-insensitive streaming applications
can also be tolerant of such delay. If the decompressor cannot
determine whether the application can tolerate delay, it should not
perform reverse decompression.
The following illustrates the decompression procedure in some detail:
1. The decompressor stores compressed packets that cannot be
decompressed correctly due to an invalid context.
2. When the decompressor has received a context updating packet and
the context has been validated, it proceeds to recover the last
packet stored. After decompression, the decompressor checks the
correctness of the reconstructed header using the CRC.
3. If the CRC indicates successful decompression, the decompressor
stores the complete packet and attempts to decompress the
preceding packet. In this way, the stored packets are recovered
in reverse order until no compressed packets are left. For each
packet, the decompressor checks the correctness of the
decompressed headers using the header compression CRC.
4. If the CRC indicates an incorrectly decompressed packet, the
reverse decompression attempt MUST be terminated and all remaining
uncompressed packets MUST be discarded.
5. Finally, the decompressor forwards all the correctly decompressed
packets to upper layers in their original order.
6.2. RTCP
RTCP is the RTP Control Protocol [RTP]. RTCP is based on periodic
transmission of control packets to all participants in a session,
using the same distribution mechanism as for data packets. Its
primary function is to provide feedback from the data receivers on
the quality of the data distribution. The feedback information may
be used for issues related to congestion control functions, and
directly useful for control of adaptive encodings.
In an RTP session there will be two types of packet streams: one with
the RTP header and application data, and one with the RTCP control
information. The difference between the streams at the transport
level is in the UDP port numbers: the RTP port number is always even,
the RTCP port number is that number plus one and therefore always odd
[RTP, section 10]. The ROHC header compressor implementation has
several ways at hand to handle the RTCP stream:
1. One compressor/decompressor entity carrying both types of streams
on the same channel, using CIDs to distinguish between them. For
sending a single RTP stream together with its RTCP packets on one
channel, it is most efficient to set LARGE_CIDS to false, send the
RTP packets with the implied CID 0 and use the Add-CID mechanism
to send the RTCP packets.
2. Two compressor/decompressor entities, one for RTP and another one
for RTCP, carrying the two types of streams on separate channels.
This means that they will not share the same CID number space.
RTCP headers may simply be sent uncompressed using profile 0x0000.
More efficiently, ROHC UDP compression (profile 0x0002) can be used.
6.3. Implementation parameters and signals
A ROHC implementation may have two kinds of parameters: configuration
parameters that are mandatory and must be negotiated between
compressor and decompressor peers, and implementation parameters that
are optional and, when used, stipulate how a ROHC implementation is
to operate.
Configuration parameters are mandatory and must be negotiated between
compressor and decompressor, so that they have the same values at
both compressor and decompressor, see section 5.1.1.
Implementation parameters make it possible for an external entity to
stipulate how an implementation of a ROHC compressor or decompressor
should operate. Implementation parameters have local significance,
are optional to use and are thus not necessary to negotiate between
compressor and decompressor. Note that this does not preclude
signaling or negotiating implementation parameters using lower layer
functionality in order to set the way a ROHC implementation should
operate. Some implementation parameters are valid only at either of
compressor or decompressor. Implementation parameters may further be
divided into parameters that allow an external entity to describe the
way the implementation should operate and parameters that allow an
external entity to trigger a specific event, i.e., signals.
6.3.1. ROHC implementation parameters at compressor
CONTEXT_REINITIALIZATION -- signal
This parameter triggers a reinitialization of the entire context at
the decompressor, both the static and the dynamic part. The
compressor MUST, when CONTEXT_REINITIALIZATION is triggered, back off
to the IR state and fully reinitialize the context by sending IR
packets with both the static and dynamic chains covering the entire
uncompressed headers until it is reasonably confident that the
decompressor contexts are reinitialized. The context
reinitialization MUST be done for all contexts at the compressor.
This parameter may for instance be used to do context relocation at,
e.g., a cellular handover that results in a change of compression
point in the radio access network.
NO_OF_PACKET_SIZES_ALLOWED -- value: positive integer
This parameter may be set by an external entity to specify the number
of packet sizes a ROHC implementation may use. However, the
parameter may be used only if PACKET_SIZES is not used by an external
entity. With this parameter set, the ROHC implementation at the
compressor MUST NOT use more different packet sizes than the value
this parameter stipulates. The ROHC implementation must itself be
able to determine which packet sizes will be used and describe these
to an external entity using PACKET_SIZES_USED. It should be noted
that one packet size might be used for several header formats, and
that the number of packet sizes can be reduced by employing padding
and segmentation.
NO_OF_PACKET_SIZES_USED _- value: positive integer
This parameter is set by the ROHC implementation to indicate how many
packet sizes it will actually use. It can be set to a large value to
indicate that no particular attempt is made to minimize that number.
PACKET_SIZES_ALLOWED -- value: list of positive integers (bytes)
This parameter, if set, governs which packet sizes in bytes may be
used by the ROHC implementation. Thus, packet sizes not in the set
of values for this parameter MUST NOT be used. Hence, an external
entity can mandate a ROHC implementation to produce packet sizes that
fit pre-configured lower layers better. If this parameter is used to
stipulate which packet sizes a ROHC implementation can use, the
following rules apply:
- A packet large enough to hold the entire IR header (both static and
dynamic chain) MUST be part of the set of sizes, unless MRRU is set
to a large enough value to allow segmentation.
- The packet size likely to be used most frequently in the SO state
SHOULD be part of the set.
- The packet size likely to be used most frequently in the FO state
SHOULD be part of the set.
PACKET_SIZES_USED -- values: set of positive integers (bytes)
This parameter describes which packet sizes a ROHC implementation
uses if NO_OF_PACKET_SIZES_ALLOWED or PACKET_SIZES_ALLOWED is used by
an external entity to stipulate how many packet sizes a ROHC
implementation should use. The information about used packet sizes
(bytes) in this parameter, may then be used to configure lower
layers.
PAYLOAD_SIZES -_ values: set of positive integer values (bytes)
This parameter is set by an external entity that wants to make use of
the PACKET_SIZES_USED parameter to indicate which payload sizes can
be expected.
When a ROHC implementation has a limited set of allowed packet sizes,
and the most preferable header format has a size that is not part of
the set, it has the following options:
- Choose the next larger header format from the allowed set. This is
probably the most efficient choice.
- Use the most preferable header format as if there were no
restrictions on size, and then add padding octets to complete a
packet of the next larger size in the allowed set.
- Use segmentation to fragment the packet into pieces that would make
up packets of sizes that are permissible (possibly after the
addition of padding to the last segment).
It should be noted that even if the two last parameters introduce the
possibility of restricting the number of packet sizes used, such
restrictions will have a negative impact on compression performance.
6.3.2. ROHC implementation parameters at decompressor
MODE -- values: [U-mode, O-mode, R-mode]
This parameter triggers a mode transition using the mechanism
described in chapter 5 when the parameter changes value, i.e., to U-
mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode) or
R-mode (Bidirectional Reliable mode). The mode transition is made
from the current mode to the new mode as signaled by the
implementation parameter. For example, if the current mode is
Bidirectional Optimistic mode, MODE should have the value O-mode. If
the MODE is changed to R-mode, a mode transition MUST be made from
Bidirectional Optimistic mode to Bidirectional Reliable mode. MODE
should not only serve as a trigger for mode transitions, but also
make it visible which mode ROHC operates in.
CLOCK_RESOLUTION -- value: nonnegative integer
This parameter indicates the system clock resolution in units of
milliseconds. A zero (0) value means that there is no clock
available. If nonzero, this parameter allows the decompressor to use
timer-based TS compression (section 4.5.4) and SN wraparound
detection (section 5.3.2.2.4). In this case, its specific value is
also significant for correctness of the algorithms.
REVERSE_DECOMPRESSION_DEPTH -- value: nonnegative integer
This parameter determines whether reverse decompression as described
in section 6.1 should be used or not, and if used, to what extent.
The value indicates the maximum number of packets that can be
buffered, and thus possibly be reverse decompressed by the
decompressor. A zero (0) value means that reverse decompression MUST
NOT be used.
6.4. Handling of resource limitations at the decompressor
In a point-to-point link, the two nodes can agree on the number of
compressed sessions they are prepared to support for this link. It
may, however, not be possible for the decompressor to accurately
predict when it will run out of resources. ROHC allows the
negotiated number of contexts to be larger than could be accommodated
in the worst case. Then, as context resources are consumed, an
attempt to set up a new context may be rejected by the decompressor,
using the REJECT option of the feedback payload.
Upon reception of a REJECT option, the compressor SHOULD wait for a
while before attempting to compress additional streams destined for
the rejecting node.
6.5. Implementation structures
This section provides some explanatory material on data structures
that a ROHC implementation will have to maintain in one form or
another. It is not intended to constrain the implementations.
6.5.1. Compressor context
The compressor context consists of a static part and a dynamic part.
The content of the static part is the same as the static chain
defined in section 5.7.7. The dynamic part consists of multiple
elements which can be categorized into four types.
a) Sliding Window (SW)
b) Translation Table (TT)
c) Flag
d) Field
These elements may be common to all modes or mode specific. The
following table summarizes all these elements.
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | GSW | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Chksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_REF_ID |
| | C_MODE | | CSRC_GEN_ID |
| | C_STATE | | CSRC_GEN_COUNT |
| | C_TRANS | | IPEH_REF_ID |
| | TS_STRIDE (if TSS = 1) | | IPEH_GEN_ID |
| | TS_OFFSET (if TSS = 1) | | IPEH_GEN_COUNT |
| | TIME_STRIDE (if TIS = 1) | | |
| | CURR_TIME (if TIS = 1) | | |
| | MAX_JITTER_CD (if TIS = 1)| | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) GSW: Generic W_LSB Sliding Window
Each element in GSW consists of all the dynamic fields in the
dynamic chain (defined in section 5.7.7) plus the fields specified
in a) but excluding the fields specified in b).
a) Packet Arrival Time (if TIS = 1)
Scaled RTP Time Stamp (if TSS = 1) (optional)
Offset_i (if RND = 0) (optional)
b) UDP Checksum, TS Stride, CSRC list, IPv6 Extension Headers
2) R_CSW: CSRC Sliding Window in R-mode
R_IESW: IPv6 Extension Header Sliding Window in R-mode
UO_CSW: CSRC Sliding Window in U/O-mode
UO_IESW: IPv6 Extension Header Sliding Window in U/O-mode
Each element in R_CSW, R_IESW, UO_CSW and UO_IESW is defined in
section 6.5.3.
3) R_CTT: CSRC Translation Table in R-mode
R_IETT: IPv6 Extension Header Translation Table in U/O-mode
UO_CTT: CSRC Translation Table in U/O-mode
UO_IETT: IPv6 Extension Header Translation Table in U/O-mode
Each element in R_CTT and R_IETT is defined in section 5.8.1.1.
Each element in UO_CTT and UO_IETT is defined in section 5.8.1.2.
4) ACKED: Indicates whether or not the decompressor has ever acked
5) CURR_TIME: The current time value (used for context relocation
when timer-based timestamp compression is used)
6) All the other flags and fields are defined elsewhere in the ROHC
document.
6.5.2. Decompressor context
The decompressor context consists of a static part and a dynamic
part. The content of the static part is the same as the static chain
defined in section 5.7.7. The dynamic part consists of multiple
elements, one of which is the nonstatic reference header that
includes all the nonstatic fields. These nonstatic fields are the
fields in the dynamic chain defined in section 5.7.7, excluding UDP
Checksum and TS_Stride. All the remaining elements can be
categorized into four types:
a) Sliding Window (SW)
b) Translation Table (TT)
d) Flag
e) Field
These elements may be mode specific or common to all modes. The
following table summarizes all these elements.
+--------+---------------------------+-------------+----------------+
| | Common to | Specific to | Specific to |
| | all modes | R-mode | U/O-mode |
+--------+---------------------------+-------------+----------------+
| SWs | | R_CSW | UO_CSW |
| | | R_IESW | UO_IESW |
+--------+---------------------------+-------------+----------------+
| TTs | | R_CTT | UO_CTT |
| | | R_IETT | UO_IETT |
+--------+---------------------------+-------------+----------------+
| Flags | UDP Checksum | | ACKED |
| | TSS, TIS | | |
| | RND, RND2 | | |
| | NBO, NBO2 | | |
+--------+---------------------------+-------------+----------------+
| Fields | Profile | | CSRC_GEN_ID |
| | D_MODE | | IPEH_GEN_ID |
| | D_STATE | | PRE_SN_V_REF |
| | D_TRANS | | |
| | TS_STRIDE (if TSS = 1) | | |
| | TS_OFFSET (if TSS = 1) | | |
| | TIME_STRIDE (if TIS = 1) | | |
| | PKT_ARR_TIME (if TIS = 1) | | |
| | LONGEST_LOSS_EVENT(O) | | |
| | CLOCK_RESOLUTION(O) | | |
| | MAX_JITTER(O) | | |
+--------+---------------------------+-------------+----------------+
1) ACKED: Indicates whether or not ACK has ever been sent.
2) PKT_ARR_TIME: The arrival time of the packet that most recently
decompressed and verified using CRC.
PRE_SN_V_REF: The sequence number of the packet verified before
the most recently verified packet.
CSRC_GEN_ID: The CSRC gen_id of the most recently received packet.
IPEH_GEN_ID: The IPv6 Extension Header gen_id of the most recently
received packet.
3) The remaining elements are as defined in the compressor context.
6.5.3. List compression: Sliding windows in R-mode and U/O-mode
In R-mode list compression (see section 5.8.2.1), each entry in the
sliding window, both at the compressor side and at the decompressor
side, has the following structure:
+---------------------+--------+------------+
| RTP Sequence Number | icount | index list |
+---------------------+--------+------------+
The table index list contains a list of index. Each of these index
corresponds to the item in the original list carried in the packet
identified by the RTP Sequence Number. The mapping between the index
and the item is identified in the translation table. The icount
field carries the number of index in the following index list.
In U/O-mode list compression, each entry in the sliding window at
both the compressor side and decompressor side has the following
structure.
+--------+--------+------------+
| Gen_id | icount | index list |
+--------+--------+------------+
The icount and index list fields are the same as defined in R-mode.
Instead of using the RTP Sequence Number to identify each entry, the
Gen_id is included in the sliding window in U/O-mode.
7. Security Considerations
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.
However, for those cases where encryption of data (and not headers)
is sufficient, RTP does specify an alternative encryption method in
which only the RTP payload is encrypted and the headers are left in
the clear. That would still allow header compression to be applied.
ROHC compression is transparent with regard to the RTP Sequence
Number and RTP Timestamp fields, so the values of those fields can be
used as the basis of payload encryption schemes (e.g., for
computation of an initialization vector).
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, UDP and RTP headers and
possibly also valid UDP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms which will
not be affected by the compression. Moreover, this header
compression scheme uses an internal checksum for verification of
reconstructed headers. This reduces the probability of producing
decompressed headers not matching the original ones without this
being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link
and thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
8. IANA Considerations
The ROHC profile identifier is a non-negative integer. In many
negotiation protocols, it will be represented as a 16-bit value. Due
to the way the profile identifier is abbreviated in ROHC packets, the
8 least significant bits of the profile identifier have a special
significance: Two profile identifiers with identical 8 LSBs should be
assigned only if the higher-numbered one is intended to supersede the
lower-numbered one. To highlight this relationship, profile
identifiers should be given in hexadecimal (as in 0x1234, which would
for example supersede 0x0A34).
Following the policies outlined in [IANA-CONSIDERATIONS], the IANA
policy for assigning new values for the profile identifier shall be
Specification Required: values and their meanings must be documented
in an RFCor in some other permanent and readily available reference,
in sufficient detail that interoperability between independent
implementations is possible. In the 8 LSBs, the range 0 to 127 is
reserved for IETF standard-track specifications; the range 128 to 254
is available for other specifications that meet this requirement
(such as Informational RFCs). The LSB value 255 is reserved for
future extensibility of the present specification.
The following profile identifiers are already allocated:
Profile Document Usage
identifier
0x0000 RFCthis ROHC uncompressed
0x0001 RFCthis ROHC RTP
0x0002 RFCthis ROHC UDP
0x0003 RFCthis ROHC ESP
9. Acknowledgments
Earlier header compression schemes described in [CJHC], [IPHC], and
[CRTP] have been important sources of ideas and knowledge.
The editor would like to extend his warmest thanks to Mikael
Degermark, who actually did a lot of the editing work, and Peter
Eriksson, who made a copy editing pass through the document,
significantly increasing its editorial consistency. Of course, all
remaining editorial problems have then been inserted by the editor.
Thanks to Andreas Jonsson (Lulea University), who supported this work
by his study of header field change patterns.
Finally, this work would not have succeeded without the continual
advice in navigating the IETF standards track, garnished with both
editorial and technical comments, from the IETF transport area
directors, Allison Mankin and Scott Bradner.
10. Intellectual Property Right Claim Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11. References
11.1. Normative References
[UDP] Postel, J., "User Datagram Protocol", STD 6,
RFC768, August 1980.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC
791, September 1981.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC2460,
December 1998.
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and
V. Jacobson, "RTP: A Transport Protocol for
Real-Time Applications", RFC1889, January
1996.
[HDLC] Simpson, W., "PPP in HDLC-like framing", STD
51, RFC1662, July 1994.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload", RFC2406, November 1998.
[NULL] Glenn, R. and S. Kent, "The NULL Encryption
Algorithm and Its Use With Ipsec", RFC2410,
November 1998.
[AH] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC2402, November 1998.
[MINE] Perkins, C., "Minimal Encapsulation within IP",
RFC2004, October 1996.
[GRE1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and
P. Traina, "Generic Routing Encapsulation
(GRE)", RFC2784, March 2000.
[GRE2] Dommety, G., "Key and Sequence Number
Extensions to GRE", RFC2890, August 2000.
[ASSIGNED] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC1700, October 1994.
11.2. Informative References
[VJHC] Jacobson, V., "Compressing TCP/IP Headers for
Low-Speed Serial Links", RFC1144, February
1990.
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP
Header Compression", RFC2507, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing
IP/UDP/RTP Headers for Low-Speed Serial Links",
RFC2508, February 1999.
[CRTPC] Degermark, M., Hannu, H., Jonsson, L.E.,
Svanbro, K., "Evaluation of CRTP Performance
over Cellular Radio Networks", IEEE Personal
Communication Magazine, Volume 7, number 4, pp.
20-25, August 2000.
[REQ] Degermark, M., "Requirements for robust
IP/UDP/RTP header compression", RFC3096, June
2001.
[LLG] Svanbro, K., "Lower Layer Guidelines for Robust
RTP/UDP/IP Header Compression", Work in
Progress.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC2434, October 1998.
12. Authors' Addresses
Carsten Bormann, Editor
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Carsten Burmeister
Panasonic European Laboratories GmbH
Monzastr. 4c
63225 Langen, Germany
Phone: +49-6103-766-263
Fax: +49-6103-766-166
EMail: burmeister@panasonic.de
Mikael Degermark
The University of Arizona
Dept of Computer Science
P.O. Box 210077
Tucson, AZ 85721-0077, USA
Phone: +1 520 621-3498
Fax: +1 520 621-4642
EMail: micke@cs.arizona.edu
Hideaki Fukushima
Matsushita Electric Industrial Co.,
Ltd006, Kadoma, Kadoma City,
Osaka, Japan
Phone: +81-6-6900-9192
Fax: +81-6-6900-9193
EMail: fukusima@isl.mei.co.jp
Hans Hannu
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 84
Fax: +46 920 20 20 99
EMail: hans.hannu@ericsson.com
Lars-Erik Jonsson
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Rolf Hakenberg
Panasonic European Laboratories GmbH
Monzastr. 4c
63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: hakenberg@panasonic.de
Tmima Koren
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134, USA
Phone: +1 408-527-6169
EMail: tmima@cisco.com
Khiem Le
2-700
Mobile Networks Laboratory
Nokia Research Center
6000 Connection Drive
Irving, TX 75039, USA
Phone: +1-972-894-4882
Fax: +1 972 894-4589
EMail: khiem.le@nokia.com
Zhigang Liu
2-700
Mobile Networks Laboratory
Nokia Research Center
6000 Connection Drive
Irving, TX 75039, USA
Phone: +1 972 894-5935
Fax: +1 972 894-4589
EMail: zhigang.liu@nokia.com
Anton Martensson
Ericsson Radio Systems AB
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
Phone: +46 8 404 3881
Fax: +46 8 757 5550
EMail: anton.martensson@era.ericsson.se
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Phone: +81-6-6900-9192
Fax: +81-6-6900-9193
EMail: akihiro@isl.mei.co.jp
Krister Svanbro
Box 920
Ericsson Erisoft AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@ericsson.com
Thomas Wiebke
Panasonic European Laboratories GmbH
Monzastr. 4c
63225 Langen, Germany
Phone: +49-6103-766-161
Fax: +49-6103-766-166
EMail: wiebke@panasonic.de
Takeshi Yoshimura
NTT DoCoMo, Inc.
3-5, Hikarinooka
Yokosuka, Kanagawa, 239-8536, Japan
Phone: +81-468-40-3515
Fax: +81-468-40-3788
EMail: yoshi@spg.yrp.nttdocomo.co.jp
Haihong Zheng
2-700
Mobile Networks Laboratory
Nokia Research Center
6000 Connection Drive
Irving, TX 75039, USA
Phone: +1 972 894-4232
Fax: +1 972 894-4589
EMail: haihong.zheng@nokia.com
Appendix A. Detailed classification of header fields
Header compression is possible thanks to the fact that most header
fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less
predictable way. When designing a header compression scheme, it is
of fundamental importance to understand the behavior of the fields in
detail.
In this appendix, all IP, UDP and RTP header fields are classified
and analyzed in two steps. First, we have a general classification
in A.1 where the fields are classified on the basis of stable
knowledge and assumptions. The general classification does not take
into account the change characteristics of changing fields because
those will vary more or less depending on the implementation and on
the application used. A less stable but more detailed analysis of
the change characteristics is then done in A.2. Finally, A.3
summarizes this appendix with conclusions about how the various
header fields should be handled by the header compression scheme to
optimize compression and functionality.
A.1. General classification
At a general level, the header fields are separated into 5 classes:
INFERRED These fields contain values that can be inferred from
other values, for example the size of the frame
carrying the packet, and thus do not have to be
handled at all by the compression scheme.
STATIC These fields are expected to be constant throughout
the lifetime of the packet stream. Static information
must in some way be communicated once.
STATIC-DEF STATIC fields whose values define a packet stream.
They are in general handled as STATIC.
STATIC-KNOWN These STATIC fields are expected to have well-known
values and therefore do not need to be communicated
at all.
CHANGING These fields are expected to vary in some way:
randomly, within a limited value set or range, or in
some other manner.
In this section, each of the IP, UDP and RTP header fields is
assigned to one of these classes. For all fields except those
classified as CHANGING, the motives for the classification are also
stated. In section A.2, CHANGING fields are further examined and
classified on the basis of their expected change behavior.
A.1.1. IPv6 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Traffic Class | 8 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the
same IP version. Accordingly, the field is classified as STATIC.
Flow Label
This field may be used to identify packets belonging to a specific
packet stream. If not used, the value should be set to zero.
Otherwise, all packets belonging to the same stream must have the
same value in this field, it being one of the fields that define
the stream. The field is therefore classified as STATIC-DEF.
Payload Length
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The field
is therefore classified as INFERRED.
Next Header
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes present and sometimes
not, will the field change its value during the lifetime of the
stream. The field is therefore classified as STATIC.
Source and Destination addresses
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| CHANGING | 2 |
+--------------+--------------+
A.1.2. IPv4 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC |
| Header Length | 4 | STATIC-KNOWN |
| Type Of Service | 8 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag | 1 | STATIC-KNOWN |
| Don't Fragment flag | 1 | STATIC |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP