RFC 4996
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
6. Encodings in ROHC-TCP (Normative)
6.1. Control Fields in ROHC-TCP
In ROHC-TCP, a number of control fields are used by the decompressor in its interpretation of the format of the packets received from the compressor. A control field is a field that is transmitted from the compressor to the decompressor, but is not part of the uncompressed header. Values for control fields can be set up in the context of both the compressor and the decompressor. Once established at the decompressor, the values of these fields should be kept until updated by another packet.
6.1.1. Master Sequence Number (MSN)
There is no field in the TCP header that can act as the master sequence number for TCP compression, as explained in [RFC4413], Section 5.6. To overcome this problem, ROHC-TCP introduces a control field called the Master Sequence Number (MSN) field. The MSN field is created at the compressor, rather than using one of the fields already present in the uncompressed header. The compressor increments the value of the MSN by one for each packet that it sends. The MSN field has the following two functions: 1. Differentiating between packets when sending feedback data. 2. Inferring the value of incrementing fields such as the IP-ID. The MSN field is present in every packet sent by the compressor. The MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent in full in IR/IR-DYN packets. The decompressor always sends the MSN as part of the feedback information. The compressor can later use the MSN to infer which packet the decompressor is acknowledging. When the MSN is initialized, it SHOULD be initialized to a random value. The compressor should only initialize a new MSN for the initial IR or IR-CR packet sent for a CID that corresponds to a context that is not already associated with this profile. In other words, if the compressor reuses the same CID to compress many TCP flows one after the other, the MSN is not reinitialized but rather continues to increment monotonically. For context replication, the compressor does not use the MSN of the base context when sending the IR-CR packet, unless the replication process overwrites the base context (i.e., Base CID == CID). Instead, the compressor uses the value of the MSN if it already exists in the ROHC-TCP context being associated with the new flow (CID); otherwise, the MSN is initialized to a new value.6.1.2. IP-ID Behavior
The IP-ID field of the IPv4 header can have different change patterns. Conceptually, a compressor monitors changes in the value of the IP-ID field and selects encoding methods and packet formats that are the closest match to the observed change pattern. ROHC-TCP defines different types of compression techniques for the IP-ID, to provide the flexibility to compress any of the behaviors it
may observe for this field: sequential in network byte order (NBO), sequential byte-swapped, random (RND), or constant to a value of zero. The compressor monitors changes in the value of the IP-ID field for a number of packets, to identify which one of the above listed compression alternatives is the closest match to the observed change pattern. The compressor can then select packet formats and encoding methods based on the identified field behavior. If more than one level of IP headers is present, ROHC-TCP can assign a sequential behavior (NBO or byte-swapped) only to the IP-ID of the innermost IP header. This is because only this IP-ID can possibly have a sufficiently close correlation with the MSN (see also Section 6.1.1) to compress it as a sequentially changing field. Therefore, a compressor MUST NOT assign either the sequential (NBO) or the sequential byte-swapped behavior to tunneling headers. The control field for the IP-ID behavior determines which set of packet formats will be used. These control fields are also used to determine the contents of the irregular chain item (see Section 6.2) for each IP header.6.1.3. Explicit Congestion Notification (ECN)
When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate whether or not ECN is used. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of all IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire Type of Service/ Traffic Class (TOS/TC) field is included in the irregular chain. When there is only one IP header present in the packet (i.e., no IP tunneling is used), this compression behavior allows the compressor to handle changes in the ECN bits by adding a single octet to the compressed header. The reason for including the ECN bits of all IP headers in the compressed packet when the control field is set is that the profile needs to efficiently compress flows containing IP tunnels using the "full-functionality option" of Section 9.1 of [RFC3168]. For these flows, a change in the ECN bits of an inner IP header is propagated to the outer IP headers. When the "limited-functionality" option is used, the compressor will therefore sometimes send one octet more
than necessary per tunnel header, but this has been considered a reasonable tradeoff when designing this profile.6.2. Compressed Header Chains
Some packet types use one or more chains containing sub-header information. The function of a chain is to group fields based on similar characteristics, such as static, dynamic, or irregular fields. Chaining is done by appending an item for each header to the chain in their order of appearance in the uncompressed packet, starting from the fields in the outermost header. Chains are defined for all headers compressed by ROHC-TCP, as listed below. Also listed are the names of the encoding methods used to encode each of these protocol headers. o TCP [RFC0793], encoding method: "tcp" o IPv4 [RFC0791], encoding method: "ipv4" o IPv6 [RFC2460], encoding method: "ipv6" o AH [RFC4302], encoding method: "ah" o GRE [RFC2784][RFC2890], encoding method: "gre" o MINE [RFC2004], encoding method: "mine" o NULL-encrypted ESP [RFC4303], encoding method: "esp_null" o IPv6 Destination Options header [RFC2460], encoding method: "ip_dest_opt" o IPv6 Hop-by-Hop Options header [RFC2460], encoding method: "ip_hop_opt" o IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt" Static chain: The static chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. In the formal description of the packet formats, this static chain item for each header is a format whose name is suffixed by "_static". The static chain is only used in IR packets.
Dynamic chain:
The dynamic chain consists of one item for each header of the
chain of protocol headers to be compressed, starting from the
outermost IP header and ending with a TCP header. The dynamic
chain item for the TCP header also contains a compressed list of
TCP options (see Section 6.3). In the formal description of the
packet formats, the dynamic chain item for each header type is a
format whose name is suffixed by "_dynamic". The dynamic chain is
used in both IR and IR-DYN packets.
Replicate chain:
The replicate chain consists of one item for each header in the
chain of protocol headers to be compressed, starting from the
outermost IP header and ending with a TCP header. The replicate
chain item for the TCP header also contains a compressed list of
TCP options (see Section 6.3). In the formal description of the
packet formats, the replicate chain item for each header type is a
format whose name is suffixed by "_replicate". Header fields that
are not present in the replicate chain are replicated from the
base context. The replicate chain is only used in the IR-CR
packet.
Irregular chain:
The structure of the irregular chain is analogous to the structure
of the static chain. For each compressed packet, the irregular
chain is appended at the specified location in the general format
of the compressed packets as defined in Section 7.3. This chain
also includes the irregular chain items for TCP options as defined
in Section 6.3.6, which are placed directly after the irregular
chain item of the TCP header, and in the same order as the options
appear in the uncompressed packet. In the formal description of
the packet formats, the irregular chain item for each header type
is a format whose name is suffixed by "_irregular". The irregular
chain is used only in CO packets.
The format of the irregular chain for the innermost IP header
differs from the format of outer IP headers, since this header is
part of the compressed base header.
6.3. Compressing TCP Options with List Compression
This section describes in detail how list compression is applied to the TCP options. In the definition of the packet formats for ROHC- TCP, the most frequent TCP options have one encoding method each, as listed in the table below. +-----------------+------------------------+ | Option name | Encoding method name | +-----------------+------------------------+ | NOP | tcp_opt_nop | | EOL | tcp_opt_eol | | MSS | tcp_opt_mss | | WINDOW SCALE | tcp_opt_wscale | | TIMESTAMP | tcp_opt_ts | | SACK-PERMITTED | tcp_opt_sack_permitted | | SACK | tcp_opt_sack | | Generic options | tcp_opt_generic | +-----------------+------------------------+ Each of these encoding methods has an uncompressed format, a format suffixed by "_list_item" and a format suffixed by "_irregular". In some cases, a single encoding method may have multiple "_list_item" or "_irregular" formats, in which case bindings inside these formats determine what format is used. This is further described in the following sections.6.3.1. List Compression
The TCP options in the uncompressed packet can be represented as an ordered list, whose order and presence are usually constant between packets. The generic structure of such a list is as follows: +--------+--------+--...--+--------+ list: | item 1 | item 2 | | item n | +--------+--------+--...--+--------+ To compress this list, ROHC-TCP uses a list compression scheme, which compresses each of these items individually and combines them into a compressed list. The basic principles of list-based compression are the following: 1) When a context is being initialized, a complete representation of the compressed list of options is transmitted. All options that have any content are present in the compressed list of items sent by the compressor.
Then, once the context has been initialized:
2) When the structure AND the content of the list are unchanged,
no information about the list is sent in compressed headers.
3) When the structure of the list is constant, and when only the
content defined within the irregular format for one or more
options is changed, no information about the list needs to be sent
in compressed base headers; the irregular content is sent as part
of the irregular chain, as described in Section 6.3.6.
4) When the structure of the list changes, a compressed list is
sent in the compressed base header, including a representation of
its structure and order. Content defined within the irregular
format of an option can still be sent as part of the irregular
chain (as described in Section 6.3.6), provided that the item
content is not part of the compressed list.
6.3.2. Table-Based Item Compression
The Table-based item compression compresses individual items sent in
compressed lists. The compressor assigns a unique identifier,
"Index", to each item, "Item", of a list.
Compressor Logic
The compressor conceptually maintains an item table containing all
items, indexed using "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
items and their respective index. Confidence is obtained from the
reception of an acknowledgment from the decompressor, or by
sending (Index, Item) pairs using the optimistic approach. Once
confidence is obtained, the index alone is sent in compressed
lists to indicate the presence of the item corresponding to this
index.
The compressor may reassign an existing index to a new item, by
re-establishing the mapping using the procedure described above.
Decompressor Logic
The decompressor conceptually maintains an item table that
contains all (Index, Item) pairs received. The item table is
updated whenever an (Index, Item) pair is received and
decompression is successfully verified using the CRC. The
decompressor retrieves the item from the table whenever an index
without an accompanying item is received.
If an index without an accompanying item is received and the
decompressor does not have any context for this index, the header
MUST be discarded and a NACK SHOULD be sent.
6.3.3. Encoding of Compressed Lists
Each item present in a compressed list is represented by:
o an index into the table of items
o a presence bit indicating if a compressed representation of the
item is present in the list
o an item (if the presence bit is set)
Decompression of an item will fail if the presence bit is not set and
the decompressor has no entry in the context for that item.
A compressed list of TCP options uses the following encoding:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |PS | m |
+---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item_1, ..., item_n / variable
| |
+---+---+---+---+---+---+---+---+
Reserved: MUST be set to zero; otherwise, the decompressor MUST
discard the packet.
PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields.
m: Number of XI item(s) in the compressed list.
XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in
the uncompressed packet, in the same order as they appear in the
uncompressed packet.
The format of an XI item is as follows:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+
X: Indicates whether the item is present in the list:
X = 1 indicates that the item corresponding to the Index is
sent in the item_1, ..., item_n list;
X = 0 indicates that the item corresponding to the Index is
not sent and is instead included in the irregular chain.
Reserved: MUST be set to zero; otherwise, the decompressor MUST
discard the packet.
Index: An index into the item table. See Section 6.3.4.
When 4-bit XI items are used, 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 the
number of XIs is odd. The Padding field MUST be set to zero;
otherwise, the decompressor MUST discard the packet.
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
XI 1, ..., XI m. The format of the entries in the item list is
described in Section 6.2.
6.3.4. Item Table Mappings
The item table for TCP options list compression is limited to 16
different items, since it is unlikely that any packet flow will
contain a larger number of unique options.
The mapping between the TCP option type and table indexes are listed
in the table below:
+-----------------+---------------+
| Option name | Table index |
+-----------------+---------------+
| NOP | 0 |
| EOL | 1 |
| MSS | 2 |
| WINDOW SCALE | 3 |
| TIMESTAMP | 4 |
| SACK-PERMITTED | 5 |
| SACK | 6 |
| Generic options | 7-15 |
+-----------------+---------------+
Some TCP options are used more frequently than others. To simplify
their compression, a part of the item table is reserved for these
option types, as shown on the table above. Both the compressor and
the decompressor MUST use these mappings between item and indexes to
(de)compress TCP options when using list compression.
It is expected that the option types for which an index is reserved
in the item table will only appear once in a list. However, if an
option type is detected twice in the same options list and if both
options have a different content, the compressor should compress the
second occurrence of the option type by mapping it to a generic
compressed option. Otherwise, if the options have the exact same
content, the compressor can still use the same table index for both.
The NOP option
The NOP option can appear more than once in the list. However,
since its value is always the same, no context information needs
to be transmitted. Multiple NOP options can thus be mapped to the
same index. Since the NOP option does not have any content when
compressed as a "_list_item", it will never be present in the item
list. For consistency, the compressor should still establish an
entry in the list by setting the presence bit, as done for the
other type of options.
List compression always preserves the original order of each item
in the decompressed list, whether or not the item is present in
the compressed "_list_item" or if multiple items of the same type
can be mapped to the same index, as for the NOP option.
The EOL option
The size of the compressed format for the EOL option can be larger
than one octet, and it is defined so that it includes the option
padding. This is because the EOL should terminate the parsing of
the options, but it can also be followed by padding octets that
all have the value zero.
The Generic option
The Generic option can be used to compress any type of TCP option
that does not have a reserved index in the item table.
6.3.5. Compressed Lists in Dynamic Chain
A compressed list for TCP options that is part of the dynamic chain
(e.g., in IR or IR-DYN packets) must have all its list items present,
i.e., all X-bits in the XI list MUST be set.
6.3.6. Irregular Chain Items for TCP Options
The "_list_item" represents the option inside the compressed item
list, and the "_irregular" format is used for the option fields that
are expected to change with each packet. When an item of the
specified type is present in the current context, these irregular
fields are present in each compressed packet, as part of the
irregular chain. Since many of the TCP option types are not expected
to change for the duration of a flow, many of the "_irregular"
formats are empty.
The irregular chain for TCP options is structured analogously to the
structure of the TCP options in the uncompressed packet. If a
compressed list is present in the compressed packet, then the
irregular chain for TCP options must not contain irregular items for
the list items that are transmitted inside the compressed list (i.e.,
items in the list that have the X-bit set in its XI). The items that
are not present in the compressed list, but are present in the
uncompressed list, must have their respective irregular items present
in the irregular chain.
6.3.7. Replication of TCP Options
The entire table of TCP options items is always replicated when using
the IR-CR packet. In the IR-CR packet, the list of options for the
new flow is also transmitted as a compressed list in the IR-CR
packet.
6.4. Profile-Specific Encoding Methods
This section defines encoding methods that are specific to this profile. These methods are used in the formal definition of the packet formats in Section 8.6.4.1. inferred_ip_v4_header_checksum
This encoding method compresses the Header Checksum field of the IPv4 header. This checksum is defined in [RFC0791] as follows: Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. The checksum algorithm is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. As described above, the header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, and when decompression is verified by a CRC computed over the original header for every compressed packet, there is no point in having this additional checksum; instead, it can be recomputed at the decompressor side. The "inferred_ip_v4_header_checksum" encoding method thus compresses the IPv4 header checksum down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field using the computation above. This encoding method implicitly assumes that the compressor will not process a corrupted header; otherwise, it cannot guarantee that the checksum as recomputed by the decompressor will be bitwise identical to its original value before compression.
6.4.2. inferred_mine_header_checksum
This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in [RFC2004] as follows: Header Checksum The 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. For purposes of computing the checksum, the value of the checksum field is 0. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation. The "inferred_mine_header_checksum" encoding method compresses the minimal encapsulation header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation. The motivations and the assumptions for inferring this checksum are similar to the ones explained above in Section 6.4.1.6.4.3. inferred_ip_v4_length
This encoding method compresses the Total Length field of the IPv4 header. The Total Length field of the IPv4 header is defined in [RFC0791] as follows: Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. The "inferred_ip_v4_length" encoding method compresses the IPv4 header checksum down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
6.4.4. inferred_ip_v6_length
This encoding method compresses the Payload Length field of the IPv6 header. This length field is defined in [RFC2460] as follows: Payload Length: 16-bit unsigned integer Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. (Note that any extension headers present are considered part of the payload, i.e., included in the length count.) The "inferred_ip_v6_length" encoding method compresses the Payload Length field of the IPv6 header down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.6.4.5. inferred_offset
This encoding method compresses the data offset field of the TCP header. The "inferred_offset" encoding method is used on the Data Offset field of the TCP header. This field is defined in [RFC0793] as: Data Offset: 4 bits The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long. The "inferred_offset" encoding method compresses the Data Offset field of the TCP header down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by first decompressing the TCP options list, and by then setting: data offset = (options length / 4) + 5 The equation above uses integer arithmetic.6.4.6. baseheader_extension_headers
In CO packets (see Section 7.3), the innermost IP header and the TCP header are combined to create a compressed base header. In some cases, the IP header will have a number of extension headers between itself and the TCP header.
To remain formally correct, the base header must define some representation of these extension headers, which is what this encoding method is used for. This encoding method skips over all the extension headers and does not encode any of the fields. Changed fields in these headers are encoded in the irregular chain.6.4.7. baseheader_outer_headers
This encoding method, as well as the baseheader_extension_headers encoding method described above, is needed for the specification to remain formally correct. It is used in CO packets (see Section 7.3) to describe tunneling IP headers and their respective extension headers (i.e., all headers located before the innermost IP header). This encoding method skips over all the fields in these headers and does not perform any encoding. Changed fields in outer headers are instead handled by the irregular chain.6.4.8. Scaled Encoding of Fields
Some header fields will exhibit a change pattern where the field increases by a constant value or by multiples of the same value. Examples of fields that may have this behavior are the TCP Sequence Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP provides the means to downscale the field value before applying LSB encoding, which allows the compressor to transmit fewer bits. To be able to use scaled encoding, the field is required to fulfill the following equation: unscaled_value = scaling_factor * scaled_value + residue To use the scaled encoding, the compressor must be confident that the decompressor has established values for the "residue" and the "scaling_factor", so that it can correctly decompress the field when only an LSB-encoded "scaled_value" is present in the compressed packet. Once the compressor is confident that the value of the scaling_factor and the value of the residue have been established in the decompressor, the compressor may send compressed packets using the scaled representation of the field. The compressor MUST NOT use scaled encoding with the value of the scaling_factor set to zero. If the compressor detects that the value of the residue has changed, or if the compressor uses a different value for the scaling factor,
it MUST NOT use scaled encoding until it is confident that the decompressor has received the new value(s) of these fields. When the unscaled value of the field wraps around, the value of the residue is likely to change, even if the scaling_factor remains constant. In such a case, the compressor must act in the same way as for any other change in the residue. The following subsections describe how the scaled encoding is applied to specific fields in ROHC-TCP, in particular, how the scaling_factor and residue values are established for the different fields.6.4.8.1. Scaled TCP Sequence Number Encoding
For some TCP flows, such as data transfers, the payload size will be constant over periods of time. For such flows, the TCP Sequence Number is bound to increase by multiples of the payload size between packets, which means that this field can be a suitable target for scaled encoding. When using this encoding, the payload size will be used as the scaling factor (i.e., as the value for scaling_factor) of this encoding. This means that the scaling factor does not need to be explicitly transmitted, but is instead inferred from the length of the payload in the compressed packet. Establishing scaling_factor: The scaling factor is established by sending unscaled TCP Sequence Number bits, so that the decompressor can infer the scaling_factor from the payload size. Establishing residue: The residue is established identically as the scaling_factor, i.e., by sending unscaled TCP Sequence Number bits. A detailed specification of how the TCP Sequence Number uses the scaled encoding can be found in the definitions of the packet formats, in Section 8.2.6.4.8.2. Scaled Acknowledgment Number Encoding
Similar to the pattern exhibited by the TCP Sequence Number, the expected increase in the TCP Acknowledgment Number is often constant and is therefore suitable for scaled encoding. For the TCP Acknowledgment Number, the scaling factor depends on the size of packets flowing in the opposite direction; this information might not be available to the compressor/decompressor pair. For this
reason, ROHC-TCP uses an explicitly transmitted scaling factor to
compress the TCP Acknowledgment Number.
Establishing scaling_factor:
The scaling factor is established by explicitly transmitting the
value of the scaling factor (called ack_stride in the formal
notation in Section 8.2) to the decompressor, using one of the
packet types that can carry this information.
Establishing residue:
The scaling factor is established by sending unscaled TCP
Acknowledgment Number bits, so that the decompressor can infer its
value from the unscaled value and the scaling factor (ack_stride).
A detailed specification of how the TCP Acknowledgment Number uses
the scaled encoding can be found in the definitions of the packet
formats, in Section 8.2.
The compressor MAY use the scaled acknowledgment number encoding;
what value it will use as the scaling factor is up to the compressor
implementation. In the case where there is a co-located decompressor
processing packets of the same TCP flow in the opposite direction,
the scaling factor for the sequence number used for that flow can be
used by the compressor to determine a suitable scaling factor for the
TCP Acknowledgment number for this flow.
6.5. Encoding Methods With External Parameters
A number of encoding methods in Section 8.2 have one or more
arguments for which the derivation of the parameter's value is
outside the scope of the ROHC-FN specification of the header formats.
This section lists the encoding methods together with a definition of
each of their parameters.
o esp_null(next_header_value):
next_header_value: Set to the value of the Next Header field
located in the ESP trailer, usually 12 octets from the end of
the packet. Compression of null-encrypted ESP headers should
only be performed when the compressor has prior knowledge of
the exact location of the Next Header field.
o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):
is_innermost: This Boolean flag is set to true when processing
the innermost IP header; otherwise, it is set to false.
ttl_irregular_chain_flag: This parameter must be set to the
value that was used for the corresponding
"ttl_irregular_chain_flag" parameter of the "co_baseheader"
encoding method (as defined below) when extracting the
irregular chain for a compressed header; otherwise, it is set
to zero and ignored for other types of chains.
ip_inner_ecn: This parameter is bound by the encoding method,
and therefore it should be undefined when calling this encoding
method. This value is then used to bind the corresponding
parameter in the "tcp" encoding method, as its value is needed
when processing the irregular chain for TCP. See the
definition of the "ip_inner_ecn" parameter for the "tcp"
encoding method below.
o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):
See definition of arguments for "ipv6" above.
o tcp_opt_eol(nbits):
nbits: This parameter is set to the length of the padding data
located after the EOL option type octet to the end of the TCP
options in the uncompressed header.
o tcp_opt_sack(ack_value):
ack_value: Set to the value of the Acknowledgment Number field
of the TCP header.
o tcp(payload_size, ack_stride_value, ip_inner_ecn):
payload_size: Set to the length (in octets) of the payload
following the TCP header.
ack_stride_value: This parameter is the scaling factor used
when scaling the TCP Acknowledgment Number. Its value is set
by the compressor implementation. See Section 6.4.8.2 for
recommendations on how to set this value.
ip_inner_ecn: This parameter binds with the value given to the
corresponding "ip_inner_ecn" parameter by the "ipv4" or the
"ipv6" encoding method when processing the innermost IP header
of this packet. See also the definition of the "ip_inner_ecn"
parameter to the "ipv6" and "ipv4" encoding method above.
o co_baseheader(payload_size, ack_stride_value,
ttl_irregular_chain_flag):
payload_size: Set to the length (in octets) of the payload
following the TCP header.
ack_stride_value: This parameter is the scaling factor used
when scaling the TCP Acknowledgment Number. Its value is set
by the compressor implementation. See Section 6.4.8.2 for
recommendations on how to set this value.
ttl_irregular_chain_flag: This parameter is set to one if the
TTL/Hop Limit of an outer header has changed compared to its
reference in the context; otherwise, it is set to zero. The
value used for this parameter is also used for the
"ttl_irregular_chain_flag" argument for the "ipv4" and "ipv6"
encoding methods when processing the irregular chain, as
defined above for the "ipv6" and "ipv4" encoding methods.
7. Packet Types (Normative)
ROHC-TCP uses three different packet types: the Initialization and
Refresh (IR) packet type, the Context Replication (IR-CR) packet
type, and the Compressed (CO) packet type.
Each packet type defines a number of packet formats: two packet
formats are defined for the IR type, one packet format is defined for
the IR-CR type, and two sets of eight base header formats are defined
for the CO type with one additional format that is common to both
sets.
The profile identifier for ROHC-TCP is 0x0006.
7.1. Initialization and Refresh (IR) Packets
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets
as defined in [RFC4995] (Sections 5.2.2.1 and 5.2.2.2, respectively).
Packet type: IR
This packet type communicates the static part and the dynamic part
of the context.
For the ROHC-TCP IR packet, the value of the x bit MUST be set to
one. It has the following format, which corresponds to the
"Header" and "Payload" fields described in Section 5.2.1 of
[RFC4995]:
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 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to Section 5.3.1.1. of
[RFC4995]. The CRC covers the entire IR header, thus excluding
payload, padding, and feedback, if any.
Static chain: See Section 6.2.
Dynamic chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The payload consists of all data after the last octet of the TCP
header to end of the uncompressed packet. The presence of a
payload is inferred from the packet length.
Packet type: IR-DYN
This packet type communicates the dynamic part of the context.
The ROHC-TCP IR-DYN packet has the following format, which
corresponds to the "Header" and "Payload" fields described in
Section 5.2.1 of [RFC4995]:
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 = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to Section 5.3.1.1 of
[RFC4995]. The CRC covers the entire IR-DYN header, thus
excluding payload, padding, and feedback, if any.
Dynamic chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The payload consists of all data after the last octet of the TCP
header to end of the uncompressed packet. The presence of a
payload is inferred from the packet length.
7.2. Context Replication (IR-CR) Packets
Context replication requires a dedicated IR packet format that
uniquely identifies the IR-CR packet for the ROHC-TCP profile. This
section defines the profile-specific part of the IR-CR packet
[RFC4164].
Packet type: IR-CR
This packet type communicates a reference to a base context along
with the static and dynamic parts of the replicated context that
differs from the base context.
The ROHC-TCP IR-CR packet follows the general format of the ROHC CR
packet, as defined in [RFC4164], Section 3.5.2. With consideration
to the extensibility of the IR packet type defined in [RFC4995], the
ROHC-TCP profile supports context replication through the profile-
specific part of the IR packet. This is achieved using the bit (x)
left in the IR header for "Profile specific information". For ROHC-
TCP, this bit is defined as a flag indicating whether this packet is
an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR packet, the
value of the x bit MUST be set to zero.
The ROHC-TCP IR-CR has the following format, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]: 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 0 | IR-CR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile = 0x06 | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | B | CRC7 | 1 octet +---+---+---+---+---+---+---+---+ : Reserved | Base CID : 1 octet, for small CID, if B=1 +---+---+---+---+---+---+---+---+ : : / Base CID / 1-2 octets, for large CIDs, : : if B=1 +---+---+---+---+---+---+---+---+ | | / Replicate chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - B: B = 1 indicates that the Base CID field is present. CRC: This CRC covers the entire IR-CR header, thus excluding payload, padding, and feedback, if any. This 8-bit CRC is calculated according to Section 5.3.1.1 of [RFC4995]. CRC7: The CRC over the original, uncompressed, header. Calculated according to Section 3.5.1.1 of [RFC4164]. Reserved: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
Base CID: CID of base context. Encoded according to [RFC4164],
Section 3.5.3.
Replicate chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
7.3. Compressed (CO) Packets
The ROHC-TCP CO packets communicate irregularities in the packet
header. All CO packets carry a CRC and can update the context.
The general format for a compressed TCP header is as follows, which
corresponds to the "Header" and "Payload" fields described in Section
5.2.1 of [RFC4995]:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| First octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of octets
+---+---+---+---+---+---+---+---+
: Irregular chain :
/ (including irregular chain / variable
: items for TCP options) :
--- --- --- --- --- --- --- ---
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
Base header: The complete set of base headers is defined in
Section 8.
Irregular chain: See Section 6.2 and Section 6.3.6.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
(next page on part 3)
