Re: RFC4996 IP-ID with co_common and Random behavior

Hi,

Comment inline.

Cheers

/Calle

On 02/27/2012 05:02 PM, RoHC Team wrote:
>  Hello everybody,
> 
>  We are coding the RFC4996 and we don't understand how to send the value
> of the IPv4 IP-ID field, using the co_common compressed format, when the
> IP-ID has a random behavior.
> 
>  With the co_common format, there are :
>  ip_id_indicator
>  ip_id_behavior
>  and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE,
>                                    ip_id_indicator.CVALUE)
> 
>  with :
> 
> optional_ip_id_lsb(behavior, indicator)
>  {
>    UNCOMPRESSED {
>      ip_id [ 16 ];
>    }
> 
>    COMPRESSED short {
>      ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
>      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
>              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
>      ENFORCE(indicator == 0);
>    }
> 
>    COMPRESSED long {
>      ip_id =:= irregular(16)  [ 16 ];
>      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
>              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
>      ENFORCE(indicator == 1);
>    }
> 
>    COMPRESSED not_present {
>      ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
>              (behavior == IP_ID_BEHAVIOR_ZERO));
>    }
>  }
> 
> 
> 
>  So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present)
> ! And we can't send the value ...
> 
>  Why not ip_id =:= irregular(16)  [ 16 ]; when behavior is RANDOM ?
> 

The FN is correct. IP-ID is sent in the irregular chain.

> 
> 
>  There is a contradiction with the paragraph 8.1 page 44/45 saying :
> 
>    All of the compressed base headers transmit LSB-encoded MSN bits, the
>    TCP Push flag, and a CRC, and in addition to this, all the base
>    headers in the sequential packet format set contain LSB-encoded IP-ID
>    bits.
> 
>   o  Common header format: The common header format can be used for all
>       kinds of IP-ID behavior and should be useful when some of the more
>       rarely changing fields in the IP or TCP header change.  Since this
>       header format can update control fields that decide how the
>       decompressor interprets packets, it carries a 7-bit CRC to reduce
>       the probability of context corruption.  This header can basically
>       convey changes to any of the dynamic fields in the IP and TCP
>       headers, and it uses a large set of flags to provide information
>       about which fields are present in the header format.
> 

I can't find any contradiction. Please be more specific.