5.7.7.4. Initialization of IPv4 Header [IPv4, section 3.1].
Static part:
Version, Protocol, Source Address, Destination Address.
+---+---+---+---+---+---+---+---+
| Version = 4 | 0 |
+---+---+---+---+---+---+---+---+
| Protocol |
+---+---+---+---+---+---+---+---+
/ Source Address / 4 octets
+---+---+---+---+---+---+---+---+
/ Destination Address / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
Type of Service, Time to Live, Identification, DF, RND, NBO,
extension header list.
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 100]
Eliminated:
IHL (IP Header Length, must be 5)
Total Length (inferred in decompressed packets)
MF flag (More Fragments flag, must be 0)
Fragment Offset (must be 0)
Header Checksum (inferred in decompressed packets)
Options, Padding (must not be present)
Extras:
RND, NBO See section 5.7.
Generic extension header list: Encoded according to section
5.8.6.1, with all header items present in uncompressed form.
CRC-DYNAMIC: Total Length, Identification, Header Checksum
(octets 3-4, 5-6, 11-12).
CRC-STATIC: All other fields (octets 1-2, 7-10, 13-20)
CRC coverage for extension headers is defined in section 5.8.7.
Note: The Protocol field indicates the type of the following header
in the static chain, rather than being a copy of the Protocol field
of the original IPv4 header. See also section 5.7.7.8.
5.7.7.5. Initialization of UDP Header [RFC-768].
Static part:
+---+---+---+---+---+---+---+---+
/ Source Port / 2 octets
+---+---+---+---+---+---+---+---+
/ Destination Port / 2 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 101]
Eliminated:
Length
The Length field of the UDP header MUST match the Length field(s)
of the preceding subheaders, i.e., there must not be any padding
after the UDP payload that is covered by the IP Length.
CRC-DYNAMIC: Length field, Checksum (octets 5-8).
CRC-STATIC: All other fields (octets 1-4).
5.7.7.6. Initialization of RTP Header [RTP].
Static part:
SSRC.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ SSRC / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
P, X, CC, PT, M, sequence number, timestamp, timestamp stride,
CSRC identifiers.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| V=2 | P | RX| CC | (RX is NOT the RTP X bit)
+---+---+---+---+---+---+---+---+
| M | PT |
+---+---+---+---+---+---+---+---+
/ RTP Sequence Number / 2 octets
+---+---+---+---+---+---+---+---+
/ RTP Timestamp (absolute) / 4 octets
+---+---+---+---+---+---+---+---+
/ Generic CSRC list / variable length
+---+---+---+---+---+---+---+---+
: Reserved | X | Mode |TIS|TSS: if RX = 1
+---+---+---+---+---+---+---+---+
: TS_Stride : 1-4 octets, if TSS = 1
+---+---+---+---+---+---+---+---+
: Time_Stride : 1-4 octets, if TIS = 1
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 102]
Eliminated:
Nothing.
Extras:
RX: Controls presence of extension.
Mode: Compression mode. 0 = Reserved,
1 = Unidirectional,
2 = Bidirectional Optimistic,
3 = Bidirectional Reliable.
X: Copy of X bit from RTP header (presumed 0 if RX = 0)
Reserved: Set to zero when sending, ignored when received.
Generic CSRC list: CSRC list encoded according to section
5.8.6.1, with all CSRC items present.
CRC-DYNAMIC: Octets containing M-bit, sequence number field,
and timestamp (octets 2-8).
CRC-STATIC: All other fields (octets 1, 9-12, original CSRC list).
5.7.7.7. Initialization of ESP Header [ESP, section 2]
This is for the case when the NULL encryption algorithm [NULL] is NOT
being used with ESP, so that subheaders after the ESP header are
encrypted (see 5.12). See 5.8.4.3 for compression of the ESP header
when NULL encryption is being used.
Static part:
+---+---+---+---+---+---+---+---+
/ SPI / 4 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets
+---+---+---+---+---+---+---+---+
Eliminated:
Other fields are encrypted, and can neither be located nor
compressed.
----------------------------------------------------------------[Page 103]
CRC-DYNAMIC: Sequence number (octets 5-8)
CRC-STATIC: All other octets.
Note: No encrypted data is considered to be part of the header for
purposes of computing the CRC, i.e., octets after the eight octet are
not considered part of the header.
5.7.7.8. Initialization of Other Headers
Headers not explicitly listed in previous subsections can be
compressed only by making them part of an extension header chain
following an IPv4 or IPv6 header, see section 5.8.
5.8. List compression
Header information from the packet stream to be compressed can be
structured as an ordered list, which is largely constant between
packets. The generic structure of such a list is as follows.
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
This section describes the compression scheme for such information.
The basic principles of list-based compression are the following:
1) While the list is constant, no information about the list is sent
in compressed headers.
2) Small changes in the list are represented as additions (Insertion
scheme), or deletions (Removal scheme), or both (Remove Then
Insert scheme).
3) The list can also be sent in its entirety (Generic scheme).
There are two kinds of lists: CSRC lists in RTP packets, and
extension header chains in IP packets (both IPv4 and IPv6).
IPv6 base headers and IPv4 headers cannot be part of an extension
header chain. Headers which can be part of extension header chains
include
a) the AH header
b) the null ESP header
c) the minimal encapsulation header [RFC2004, section 3.1]
d) the GRE header [GRE1, GRE2]
e) IPv6 extension headers.
----------------------------------------------------------------[Page 104]
The table-based item compression scheme (5.8.1), which reduces the
size of each item, is described first. Then it is defined which
reference list to use in the insertion and removal schemes (5.8.2).
List encoding schemes are described in section 5.8.3, and a few
special cases in section 5.8.4. Finally, exact formats are described
in sections 5.8.5-5.8.6.
5.8.1. Table-based item compression
The Table-based item compression scheme is a way to compress
individual items sent in compressed lists. The compressor assigns
each item in a list a unique identifier Index. The compressor
conceptually maintains a table with all items, indexed by Index. The
(Index, item) pair is sent together in compressed lists until the
compressor gains enough confidence that the decompressor has observed
the mapping between the item and its Index. Such confidence is
obtained by receiving an acknowledgment from the decompressor in R-
mode, and in U/O-mode by sending L (Index, item) pairs (not
necessarily consecutively). After that, the Index alone is sent in
compressed lists to indicate the corresponding item. The compressor
may reassign an existing Index to a new item, and then needs to re-
establish the mapping in the same manner as above.
The decompressor conceptually maintains a table that contains all
(Index, item) pairs it knows about. The table is updated whenever an
(Index, item) pair is received (and decompression is verified by a
CRC). The decompressor retrieves the item from the table whenever an
Index without an accompanying item is received.
5.8.1.1. Translation table in R-mode
At the compressor side, an entry in the Translation Table has the
following structure.
+-------+------+---------------+
Index i | Known | item | SN1, SN2, ... |
+-------+------+---------------+
The Known flag indicates whether the mapping between Index i and item
has been established, i.e., if Index i alone can be sent in
compressed lists. Known is initially zero. It is also set to zero
whenever Index i is assigned to a new item. Known is set to one when
the corresponding (Index, item) pair is acknowledged.
Acknowledgments are based on the RTP Sequence Number, so a list of
RTP Sequence Numbers of all packets which contain the (Index, item)
pair is included in the translation table. When a packet with a
sequence number in the sequence number list is acknowledged, the
Known flag is set, and the sequence number list can be discarded.
----------------------------------------------------------------[Page 105]
Each entry in the Translation Table at the decompressor side has the
following structure:
+-------+------+
Index i | Known | item |
+-------+------+
All Known fields are initialized to zero. Whenever the decompressor
receives an (Index, item) pair, it inserts item into the table at
position Index and sets the Known flag in that entry to one. If an
index without an accompanying item is received for which the Known
flag is zero, the header MUST be discarded and a NACK SHOULD be sent.
5.8.1.2. Translation table in U/O-modes
At the compressor side, each entry in the Translation Table has the
following structure:
+-------+------+---------+
Index | Known | item | Counter |
+-------+------+---------+
The Index, Known, and item fields have the same meaning as in section
5.8.1.1.
Known is set when the (Index, item) pair has been sent in L
compressed lists (not necessarily consecutively). The Counter field
keeps track of how many times the pair has been sent. Counter is set
to 0 for each new entry added to the table, and whenever Index is
assigned to a new item. Counter is incremented by 1 whenever an
(Index, item) pair is sent. When the counter reaches L, the Known
field is set and after that only the Index needs to be sent in
compressed lists.
At the decompressor side, the Translation Table is the same as the
Translation Table defined in R-mode.
5.8.2. Reference list determination
In reference based compression schemes (i.e., addition or deletion
based schemes), compression and decompression of a list (curr_list)
are based on a reference list (ref_list) which is assumed to be
present in the context of both compressor and decompressor. The
compressed list is an encoding of the differences between curr_list
and ref_list. Upon reception of a compressed list, the decompressor
applies the differences to its reference list in order to obtain the
original list.
----------------------------------------------------------------[Page 106]
To identify the reference list (to be) used, each compressed list
carries an identifier (ref_id). The reference list is established by
different methods in R-mode and U/O-mode.
5.8.2.1. Reference list in R-mode and U/O-mode
In R-mode, the choice of reference list is based on acknowledgments,
i.e., the compressor uses as ref_list the latest list which has been
acknowledged by the decompressor. The ref_list is updated only upon
receiving an acknowledgment. The least significant bits of the RTP
Sequence Number of the acknowledged packet are used as the ref_id.
In U/O-mode, a sequence of identical lists are considered as
belonging to the same generation and are all assigned the same
generation identifier (gen_id). Gen_id increases by 1 each time the
list changes and is carried in compressed and uncompressed lists that
are candidates for being used as reference lists. Normally, Gen_id
must have been repeated in at least L headers before the list can be
used as a ref_list. However, some acknowledgments may be sent in O-
mode (and also in U-mode), and whenever an acknowledgment for a
header is received, the list of that header is considered known and
need not be repeated further. The least significant bits of the
Gen_id is used as the ref_id in U/O-mode.
The logic of the compressor and decompressor for reference based list
compression is similar to that for SN and TS. The principal
difference is that the decompressor maintains a sliding window with
candidates for ref_list, and retrieves ref_list from the sliding
window using the ref_id of the compressed list.
Logic of compressor:
a) In the IR state, the compressor sends Generic lists (see 5.8.5)
containing all items of the current list in order to establish or
refresh the context of the decompressor.
In R-mode, such Generic lists are sent until a header is
acknowledged. The list of that header can be used as a reference
list to compress subsequent lists.
In U/O-mode, the compressor sends generation identifiers with the
Generic lists until
1) a generation identifier has been repeated L times, or
2) an acknowledgment for a header carrying a generation identifier
has been received.
----------------------------------------------------------------[Page 107]
The repeated (1) or acknowledged (2) list can be used as a
reference list to compress subsequent lists and is kept together
with its generation identifier.
b) When not in the IR state, the compressor moves to the FO state
when it observes a difference between curr_list and the previous
list. It sends compressed lists based on ref_list to update the
context of the decompressor. (However, see d).)
In R-mode, the compressor keeps sending compressed lists using the
same reference until it receives an acknowledgment for a packet
containing the newest list. The compressor may then move to the
SO state with regard to the list.
In U/O-mode, the compressor keeps sending compressed lists with
generation identifiers until
1) a generation identifier has been repeated L times, or
2) an acknowledgment for a header carrying the latest generation
identifier has been received.
The repeated or acknowledged list is used as the future reference
list. The compressor may move to the SO state with regard to the
list.
c) In R-mode, the compressor maintains a sliding window containing
the lists which have been sent to update the context of the
decompressor and have not yet been acknowledged. The sliding
window shrinks when an acknowledgment arrives: all lists sent
before the acknowledged list are removed. The compressor may use
the Index to represent items of lists in the sliding window.
In U/O-mode, the compressor needs to store
1) the reference list and its generation identifier, and
2) if the current generation identifier is different from the
reference generation, the current list and the sequence
numbers with which the current list has been sent.
(2) is needed to determine if an acknowledgment concerns the
latest generation. It is not needed in U-mode.
d) In U/O-mode, the compressor may choose to not send a generation
identifier with a compressed list. Such lists without generation
identifiers are not assigned a new generation identifier and must
----------------------------------------------------------------[Page 108]
not be used as future reference lists. They do not update the
context. This feature is useful when a new list is repeated few
times and the list then reverts back to its old value.
Logic of decompressor:
e) In R-mode, the decompressor acknowledges all received uncompressed
or compressed lists which establish or update the context. (Such
compressed headers contain a CRC.)
In O-mode, the decompressor MAY acknowledge a list with a new
generation identifier, see section 5.4.2.2.
In U-mode, the decompressor MAY acknowledge a list sent in an IR
packet, see section 5.3.2.3.
f) The decompressor maintains a sliding window which contains the
lists that may be used as reference lists.
In R-mode, the sliding window contains lists which have been
acknowledged but not yet used as reference lists.
In U/O-mode, the sliding window contains at most one list per
generation. It contains all generations seen by the decompressor
newer than the last generation used as a reference.
g) When the decompressor receives a compressed list, it retrieves the
proper ref_list from the sliding window based on the ref_id, and
decompresses the compressed list obtaining curr_list.
In R-mode, curr_list is inserted into the sliding window if an
acknowledgment is sent for it. The sliding window is shrunk by
removing all lists received before ref_list.
In U/O-mode, curr_list is inserted into the sliding window
together with its generation identifier if the compressed list had
a generation identifier and the sliding window does not contain a
list with that generation identifier. All lists with generations
older than ref_id are removed from the sliding window.
5.8.3. Encoding schemes for the compressed list
Four encoding schemes for the compressed list are described here.
The exact formats of the compressed CSRC list and compressed IP
extension header list using these encoding schemes are described in
sections 5.8.5-5.8.6.
----------------------------------------------------------------[Page 109]
Generic scheme
In contrast to subsequent schemes, this scheme does not rely on a
reference list having been established. The entire list is sent,
using table based compression for each individual item. The
generic scheme is always used when establishing the context of the
decompressor and may also be used at other times, as the
compressor sees fit.
Insertion Only scheme
When the new list can be constructed from ref_list by adding
items, a list of the added items is sent (using table based
compression), along with the positions in ref_list where the new
items will be inserted. An insertion bit mask indicates the
insertion positions in ref_list.
Upon reception of a list compressed according to the Insertion
Only scheme, curr_list is obtained by scanning the insertion bit
mask from left to right. When a '0' is observed, an item is
copied from the ref_list. When a '1' is observed, an item is
copied from the list of added items. If a '1' is observed when
the list of added items has been exhausted, an error has occurred
and decompression fails: The header MUST NOT be delivered to upper
layers; it should be discarded, and MUST NOT be acknowledged nor
used as a reference.
To construct the insertion bit mask and the list of added items,
the compressor MAY use the following algorithm:
1) An empty bit list and an empty Inserted Item list are generated
as the starting point.
2) Start by considering the first item of curr_list and ref_list.
3) If curr_list has a different item than ref_list,
a set bit (1) is appended to the bit list;
the first item in curr_list (represented using table-based
item compression) is appended to the Inserted Item list;
advance to the next item of curr_list;
otherwise,
a zero bit (0) is appended to the bit list;
advance to the next item of curr_list;
advance to the next item of ref_list.
----------------------------------------------------------------[Page 110]
4) Repeat 3) until curr_list has been exhausted.
5) If the length of the bit list is less than the required bit
mask length, append additional zeroes.
Removal Only scheme
This scheme can be used when curr_list can be obtained by removing
some items in ref_list. The positions of the items which are in
ref_list, but not in curr_list, are sent as a removal bit mask.
Upon reception of the compressed list, the decompressor obtains
curr_list by scanning the removal bit mask from left to right.
When a '0' is observed, the next item of ref_list is copied into
curr_list. When a '1' is observed, the next item of ref_list is
skipped over without being copied. If a '0' is observed when
ref_list has been exhausted, an error has occurred and
decompression fails: The header MUST NOT be delivered to upper
layers; it should be discarded, and MUST NOT be acknowledged nor
used as a reference.
To construct the removal bit mask and the list of added items, the
compressor MAY use the following algorithm:
1) An empty bit list is generated as the starting point.
2) Start by considering the first item of curr_list and ref_list.
3) If curr_list has a different item than ref_list,
a set bit (1) is appended to the bit list;
advance to the next item of ref_list;
otherwise,
a zero bit (0) is appended to the bit list;
advance to the next item of curr_list;
advance to the next item of ref_list.
4) Repeat 3) until curr_list has been exhausted.
5) If the length of the bit list is less than the required bit
mask length, append additional ones.
----------------------------------------------------------------[Page 111]
Remove Then Insert scheme
In this scheme, curr_list is obtained by first removing items from
ref_list, and then inserting items into the resulting list. A
removal bit mask, an insertion bit mask, and a list of added items
are sent.
Upon reception of the compressed list, the decompressor processes
the removal bit mask as in the Removal Only scheme. The resulting
list is then used as the reference list when the insertion bit
mask and the list of added items are processed, as in the
Insertion Only scheme.
5.8.4. Special handling of IP extension headers
In CSRC list compression, each CSRC is assigned an index. In
contrast, in IP extension header list compression an index is usually
associated with a type of extension header. When there is more than
one IP header, there is more than one list of extension headers. An
index per type per list is then used.
The association with a type means that a new index need not always be
used each time a field in an IP extension header changes. However,
when a field in an extension header changes, the mapping between the
index and the new value of the extension header needs to be
established, except in the special handling cases defined in the
following subsections.
5.8.4.1. Next Header field
The next header field in an IP header or extension header changes
whenever the type of the immediately following header changes, e.g.,
when a new extension header is inserted after it, when the immediate
subsequent extension header is removed from the list, or when the
order of extension headers is changed. Thus it may not be uncommon
that, for a given header, the next header field changes while the
remaining fields do not change.
Therefore, in the case that only the next header field changes, the
extension header is considered to be unchanged and rules for special
treatment of the change in the next header field are defined below.
All communicated uncompressed extension header items indicate their
own type in their Next Header field. Note that the rules below
explain how to treat the Next Header fields while showing the
conceptual reference list as an exact recreation of the original
uncompressed extension header list.
----------------------------------------------------------------[Page 112]
a) When a subsequent extension header is removed from the list, the
new value of the next header field is obtained from the reference
extension header list. For example, assume that the reference
header list (ref_list) consists of headers A, B and C (ref_ext_hdr
A, B, C), and the current extension header list (curr_list) only
consists of extension headers A and C (curr_ext_hdr A, C). The
order and value of the next header fields of these extension
headers are as follows.
ref_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr B ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr C
Comparing the curr_ext_hdr A in curr_list and the ref_ext_hdr A in
ref_list, the value of next header field is changed from "type B"
to "type C" because of the removal of extension header B. The new
value of the next header field in curr_ext_hdr A, i.e., "type C",
does not need to be sent to the decompressor. Instead, it is
retrieved from the next header field of the removed ref_ext_hdr B.
b) When a new extension header is inserted after an existing
extension header, the next header field in the communicated item
will carry the type of itself, rather than the type of the header
that follows. For example, assume that the reference header list
(ref_list) consists of headers A and C (ref_ext_hdr A, C), and the
current header list (curr_list) consists of headers A, B and C
(curr_ext_hdr A, B, C). The order and the value of the next
header fields of these extension headers are as follows.
----------------------------------------------------------------[Page 113]
ref_list:
+--------+-----+ +--------+-----+
| type C | | | type D | |
+--------+ | +--------+ |
| | | |
+--------------+ +--------------+
ref_ext_hdr A ref_ext_hdr C
curr_list:
+--------+-----+ +--------+-----+ +--------+-----+
| type B | | | type C | | | type D | |
+--------+ | +--------+ | +--------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
curr_ext_hdr A curr_ext_hdr B curr_ext_hdr C
Comparing the curr_list and the ref_list, the value of the next
header field in extension header A is changed from "type C" to
"type B".
The uncompressed curr_ext_hdr B is carried in the compressed
header list. However, it carries "type B" instead of "type C" in
its next header field. When the decompressor inserts a new header
after curr_ext_hdr A, the next header field of A is taken from the
new header, and the next header field of the new header is taken
from ref_ext_hdr A.
c) Some headers whose compression is defined in this document do not
contain Next Header fields or do not have their Next Header field
in the standard position (first octet of the header). The GRE and
ESP headers are such headers. When sent as uncompressed items in
lists, these headers are modified so that they do have a Next
Header field as their first octet (see 5.8.4.3 and 5.8.4.4). This
is necessary to enable the decompressor to decode the item.
5.8.4.2. Authentication Header (AH)
The sequence number field in the AH [AH] contains a monotonically
increasing counter value for a security association. Therefore, when
comparing curr_list with ref_list, if the sequence number in AH
changes and SPI field does not change, the AH is not considered as
changed.
If the sequence number in the AH linearly increases as the RTP
Sequence Number increases, and the compressor is confident that the
decompressor has obtained the pattern, the sequence number in AH need
not be sent. The decompressor applies linear extrapolation to
reconstruct the sequence number in the AH.
----------------------------------------------------------------[Page 114]
Otherwise, a compressed sequence number is included in the IPX
compression field in an Extension 3 of an UOR-2 header.
The authentication data field in AH changes from packet to packet and
is sent as-is. If the uncompressed AH is sent, the authentication
data field is sent inside the uncompressed AH; otherwise, it is sent
after the compressed IP/UDP/RTP and IPv6 extension headers and before
the payload. See beginning of section 5.7.
Note: The payload length field of the AH uses a different notion of
length than other IPv6 extension headers.
5.8.4.3. Encapsulating Security Payload Header (ESP)
When the Encapsulating Security Payload Header (ESP) [ESP] is present
and an encryption algorithm other than NULL is being used, the UDP
and RTP headers are both encrypted and cannot be compressed. The ESP
header thus ends the compressible header chain. The ROHC ESP profile
defined in section 5.12 MAY be used for the stream in this case.
A special case is when the NULL encryption algorithm is used. This
is the case when the ESP header is used for authentication only, and
not for encryption. The payload is not encrypted by the NULL
encryption algorithm, so compression of the rest of the header chain
is possible. The rest of this section describes compression of the
ESP header when the NULL encryption algorithm is used with ESP.
It is not possible to determine whether NULL encryption is used by
inspecting a header in the stream, this information is present only
at the encryption endpoints. However, a compressor may attempt
compression under the assumption that the NULL encryption algorithm
is being used, and later abort compression when the assumption proves
to be false.
The compressor may, for example, inspect the Next Header fields and
the header fields supposed to be static in subsequent headers in
order to determine if NULL encryption is being used. If these change
unpredictably, an encryption algorithm other than NULL is probably
being used and compression of subsequent headers SHOULD be aborted.
Compression of the stream is then either discontinued, or a profile
that compresses only up to the ESP header may be used (see 5.12).
While attempting to compress the header, the compressor should use
the SPI of the ESP header together with the destination IP address as
the defining fields for determining which packets belong to the
stream.
----------------------------------------------------------------[Page 115]
In the ESP header [ESP, section 2], the fields that can be compressed
are the SPI, the sequence number, the Next Header, and the padding
bytes if they are in the standard format defined in [ESP]. (As
always, the decompressor reinserts these fields based on the
information in the context. Care must be taken to correctly reinsert
all the information as the Authentication Data must be verified over
the exact same information it was computed over.)
ESP header [ESP, section 2]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data |
+ (variable length, but assumed to be 12 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI: Static. If it changes, it needs to be reestablished.
Sequence Number: Not sent when the offset from the sequence number
of the compressed header is constant. When the offset is not
constant, the sequence number may be compressed by sending
LSBs. See 5.8.4.
Payload Data: This is where subsequent headers are to be found.
Parsed according to the Next Header field.
Padding: The padding octets are assumed to be as defined in [ESP],
i.e., to take the values 1, 2, ..., k, where k = Pad Length.
If the padding in the static context has this pattern, padding
in compressed headers is assumed to have this pattern as well
and is removed. If padding in the static context does not
have this pattern, the padding is not removed.
----------------------------------------------------------------[Page 116]
Pad Length: Dynamic. Always sent. 14th octet from end of packet.
Next Header: Static. 13th octet from end of packet.
Authentication Data: Can have variable length, but when compression
of NULL-encryption ESP header is attempted, it is assumed to have
length 12 octets.
The sequence number in ESP has the same behavior as the sequence
number field in AH. When it increases linearly, it can be compressed
to zero bits. When it does not increase linearly, a compressed
sequence number is included in the IPX compression field in an
Extension 3 of an UOR-2 header.
The information which is part of an uncompressed item of a compressed
list is the Next Header field, followed by the SPI and the Sequence
Number. Padding, Pad Length, Next Header, and Authentication Data
are sent as-is at the end of the packet. This means that the Next
Header occurs in two places.
Uncompressed ESP list item:
+---+---+---+---+---+---+---+---+
| Next Header ! 1 octet (see section 5.8.4.1)
+---+---+---+---+---+---+---+---+
/ SPI / 4 octets
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets
+---+---+---+---+---+---+---+---+
When sending Uncompressed ESP list items, all ESP fields near the
the end of the packet are left untouched (Padding, Pad Length,
Next Header, Authentication Data).
A compressed item consists of a compressed sequence number. When an
item is compressed, Padding (if it follows the 1, 2, ..., k pattern)
and Next Header are removed near the end of the packet.
Authentication Data and Pad Length remain as-is near the end of the
packet.
5.8.4.4. GRE Header [RFC 2784, RFC 2890]
The GRE header is a set of flags, followed by a mandatory Protocol
Type and optional parts as indicated by the flags.
----------------------------------------------------------------[Page 117]
The sequence number field in the GRE header contains a counter value
for a GRE tunnel. Therefore, when comparing curr_list with ref_list,
if the sequence number in GRE changes, the GRE is not considered as
changed.
If the sequence number in the GRE header linearly increases as the
RTP Sequence Number increases and the compressor is confident that
the decompressor has received the pattern, the sequence number in GRE
need not be sent. The decompressor applies linear extrapolation to
reconstruct the sequence number in the GRE header.
Otherwise, a compressed sequence number is included in the IPX
compression field in an Extension 3 of an UOR-2 header.
The checksum data field in GRE, if present, changes from packet to
packet and is sent as-is. If the uncompressed GRE header is sent,
the checksum data field is sent inside the uncompressed GRE header;
otherwise, if present, it is sent after the compressed IP/UDP/RTP and
IPv6 extension headers and before the payload. See beginning of
section 5.7.
In order to allow simple parsing of lists of items, an uncompressed
GRE header sent as an item in a list is modified from the original
GRE header in the following manner: 1) the 16-bit Protocol Type field
that encodes the type of the subsequent header using Ether types (see
Ether types section in [ASSIGNED]) is removed. 2) A one-octet Next
Header field is inserted as the first octet of the header. The value
of the Next Header field corresponds to GRE (this value is 47
according to the Assigned Internet Protocol Number section of
[ASSIGNED]) when the uncompressed item is to be inserted in a list,
and to the type of the subsequent header when the uncompressed item
is in a Generic list. Note that this implies that only GRE headers
with Ether types that correspond to an IP protocol number can be
compressed.
Uncompressed GRE list item:
+---+---+---+---+---+---+---+---+
| Next Header ! 1 octet (see section 5.8.4.1)
+---+---+---+---+---+---+---+---+
/ C | | K | S | | Ver | 1 octet
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets, if C=1
+---+---+---+---+---+---+---+---+
/ Key / 4 octets, if K=1
+---+---+---+---+---+---+---+---+
/ Sequence Number / 4 octets, if S=1
+---+---+---+---+---+---+---+---+
----------------------------------------------------------------[Page 118]
The bits left blank in the second octet are set to zero when
sending and ignored when received.
The fields Reserved0 and Reserved1 of the GRE header [GRE2] must
be all zeroes; otherwise, the packet cannot be compressed by this
profile.
5.8.5. Format of compressed lists in Extension 3
5.8.5.1. Format of IP Extension Header(s) field
In Extension 3 (section 5.7.5), there is a field called IP extension
header(s). This section describes the format of that field.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| CL | ASeq| ESeq| Gseq| res | 1 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
: compressed AH Seq Number, 1 or 4 octets : if ASeq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed ESP Seq Number, 1 or 4 octets : if Eseq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed GRE Seq Number, 1 or 4 octets : if Gseq = 1
----- ----- ----- ----- ----- ----- ----- -----
: compressed header list, variable length : if CL = 1
----- ----- ----- ----- ----- ----- ----- -----
ASeq: indicates presence of compressed AH Seq Number
ESeq: indicates presence of compressed ESP Seq Number
GSeq: indicates presence of compressed GRE Seq Number
CL: indicates presence of compressed header list
res: reserved; set to zero when sending, ignored when received
When Aseq, Eseq, or Gseq is set, the corresponding header item (AH,
ESP, or GRE header) is compressed. When not set, the corresponding
header item is sent uncompressed or is not present.
The format of compressed AH, ESP and GRE Sequence Numbers can each be
either of the following:
----------------------------------------------------------------[Page 119]
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | LSB of sequence number | | 1 | |
+---+---+---+---+---+---+---+---+ +---+ +
| |
+ LSB of sequence number +
| |
+ +
| |
+---+---+---+---+---+---+---+---+
The format of the compressed header list field is described in
section 5.8.6.
5.8.5.2. Format of Compressed CSRC List
The Compressed CSRC List field in the RTP header part of an Extension
3 (section 5.7.5) is as in section 5.8.6.
5.8.6. Compressed list formats
This section describes the format of compressed lists. The format is
the same for CSRC lists and header lists. In CSRC lists, the items
are CSRC identifiers; in header lists, they are uncompressed or
compressed headers, as described in 5.8.4.2-4.
5.8.6.1. Encoding Type 0 (generic scheme)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=0 |GP |PS | CC = m |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| XI 1, ..., XI m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
ET: Encoding type is zero.
PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields.
----------------------------------------------------------------[Page 120]
GP: Indicates presence of gen_id field.
CC: CSRC counter from original RTP header.
gen_id: Identifier for a sequence of identical lists. It is
present in U/O-mode when the compressor decides that it may use
this list as a future reference list.
XI 1, ..., XI m: m XI items. The format of an XI item is as
follows:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Index |
+---+---+---+---+---+---+---+---+
X = 1 indicates that the item corresponding to the Index
is sent in the item 0, ..., item n list.
X = 0 indicates that the item corresponding to the Index is
not sent.
When 4-bit XI items are used and m > 1, the XI items are placed in
octets in the following manner:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI k | XI k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and m is
odd. The Padding field is set to zero when sending and ignored
when receiving.
Item 1, ..., item n:
Each item corresponds to an XI with X = 1 in XI 1, ..., XI m.
----------------------------------------------------------------[Page 121]
5.8.6.2. Encoding Type 1 (insertion only scheme)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=1 |GP |PS | XI 1 |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ insertion bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
| XI list | k octets, or (k - 1) * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and k is even
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
Unless explicitly stated otherwise, fields have the same meaning and
values as for encoding type 0.
ET: Encoding type is one (1).
XI 1: When PS = 0, the first 4-bit XI item is placed here.
When PS = 1, the field is set to zero when sending, and
ignored when receiving.
ref_id: The identifier of the reference CSRC list used when the
list was compressed. It is the 8 least significant bits of
the RTP Sequence Number in R-mode and gen_id (see section
5.8.2) in U/O-mode.
insertion bit mask: Bit mask indicating the positions where new
items are to be inserted. See Insertion Only scheme in
section 5.8.3. The bit mask can have either of the
following two formats:
----------------------------------------------------------------[Page 122]
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 7-bit mask | bit 1 is the first bit
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| 1 | | bit 1 is the first bit
+---+ 15-bit mask +
| | bit 7 is the last bit
+---+---+---+---+---+---+---+---+
XI list: XI fields for items to be inserted. When the insertion
bit mask has k ones, the total number of XI fields is k. When
PS = 1, all XI fields are in the XI list. When PS = 0, the
first XI field is in the XI 1 field, and the remaining k - 1
XI fields are in the XI list.
Padding: Present when PS = 0 and k is even.
item 1, ..., item n: One item for each XI field with the X bit
set.
5.8.6.3. Encoding Type 2 (removal only scheme)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=2 |GP |res| Count |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
Unless explicitly stated otherwise, fields have the same meaning
and values as in section 5.8.5.2.
ET: Encoding type is 2.
res: Reserved. Set to zero when sending, ignored when
received.
Count: Number of elements in ref_list.
----------------------------------------------------------------[Page 123]
removal bit mask: Indicates the elements in ref_list to be
removed in order to obtain the current list. See section
5.8.3. The removal bit mask has the same format as the
insertion bit mask of section 5.8.6.3.
5.8.6.4. Encoding Type 3 (remove then insert scheme)
See section 5.8.3 for a description of the Remove then insert
scheme.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| ET=3 |GP |PS | XI 1 |
+---+---+---+---+---+---+---+---+
: gen_id : 1 octet, if GP = 1
+---+---+---+---+---+---+---+---+
| ref_id |
+---+---+---+---+---+---+---+---+
/ removal bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
/ insertion bit mask / 1-2 octets
+---+---+---+---+---+---+---+---+
| XI list | k octets, or (k - 1) * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and k is even
+---+---+---+---+---+---+---+---+
| |
/ item 1, ..., item n / variable
| |
+---+---+---+---+---+---+---+---+
The fields in this header have the same meaning and formats as in
section 5.8.5.2, except when explicitly stated otherwise below.
ET: Encoding type is 3.
removal bit mask: See section 5.8.6.3.
Next To :: RObust Header Compression - Part 6
Credits
-- UnKnown --
|