RE: [rohc] ROHC-FN and TCP Profile

The FIELD(n) encoding method takes the next n bits from the

uncompressed header and stores them in a temporary variable

called Field_Value. The NEXT_FIELD encoding method works

in a similar manner, but rather than taking the bits from the

uncompressed header, it takes them from a labelled field instead.

As you spotted in the TCP/IP profile, it's possible to encounter

an instance of NEXT_FIELD immediately followed by an instance

of FIELD(n). In this case the NEXT_FIELD encoding method is

considered to "win" - i.e. the Field_Value is taken from the

labelled field rather than from the uncompressed header. We

can see that this is the case from the following pseudocode, taken

from the definition of FIELD(n):

If Field_Value == Null then set Field_Value:= F and set
Remaining_Data := Remaining_Data - n.

So, the FIELD(n) encoding method must first check whether

the Field_Value temporary variable already contains a field value

or not. If it doesn't then the next n bits are extracted from the

uncompressed header as expected. However, if the NEXT_FIELD

encoding method has been used previously, then Field_Value

will already be set and the FIELD(n) encoding method will be

This behaviour is a little clumsy, so why do we need it? The

benefit is that we can compress labelled fields using ordinary

encoding methods such as STATIC and IRREGULAR, e.g:

                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

As you pointed out, the STATIC and IRREGULAR encoding

methods both call an instance of FIELD(n) to extract some

bits from the uncompressed header. Using the NEXT_FIELD

encoding method we can "override" this default behaviour and

force them to compress a labelled field instead.

If you can think of a neater way of doing this then please let

Hi, Richard,

I am confused on the definition of FIELD and NEXT_FIELD.

According to ROHC-FN draft, FIELD encoding method extracts an n-bit field from the uncompressed packet and stores it in a temporary variable. It means this encoding method operates on the header rather than any label or temporary varialbe. NEXT_FIELD instead operates on labeled field. See the example where NEXT_FIELD is used as follows.

tcp_options           -->   list(data_offset,1,32,-160,
                             [optional(tcp_sack),
                              optional(tcp_timestamp),
                              optional(tcp_end),
                              optional(tcp_no_operation),
                              optional(tcp_no_operation),
                              optional(tcp_generic),
                              optional(tcp_generic),
                              optional(tcp_generic)])++
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

The encoding method that follows the next_field is either STATIC or IRREGULAR, both further using FIELD encoding method via RANGE. It seems quite difficult to understand we can use FIELD encoding method when a labeled field is expected to be encoded/decoded. Consider that following next_field(order)++ we expect to add the labeled field 'order' to the compressed header, but when we use static or irregular(24), we point to the uncompressed header and try to shift the 'remaining_data'. But this is not the action we want to take, is it right?

Thanks.

RGDS,

William

RE: [rohc] ROHC-FN and TCP Profile - Version 3