Hello,

It looks like you are looking at the optional_ip_id_lsb encoding method on page 76. This encoding method is only used in the co_common compressed format (page 80), which I believe is what you are concerned with. In the optional_ip_id_lsb encoding method, the compressed ip_id has no bindings in the "not_present" case. That is, the not_present format leaves the ip_id to be defined elsewhere - it does not define it as absent (i.e. zero bits compressed length), which is, I suspect, how you may have interpreted the FN.

The English name for the format I think has misled you here. Remember that the header is defined in multiple chains (section 6.2 on page 21). I haven't looked but I assume the "not_present" format name is referring to the fact that the ip_id is not present in this chain. The ip_id must be defined in a different chain in this case. If it was not defined anywhere then the spec would be in error.

Caveat I am not that familiar with RFC 4996 so I may have misunderstood, but this is how the FN looks to me.

I hope this helps

Regards

R <at> ffles

On 05/03/2012 09:59, RoHC Team wrote:

 Hello Carl,

 When using co_common compressed packet format, described page 80 of the RFC, ip_id is optionaly sent with the optional_ip_id_lsb{} method. Ok.

 But when the IP-ID behavior is random, the value is not present in the header :

     COMPRESSED not_present {
       ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
               (behavior == IP_ID_BEHAVIOR_ZERO));
     }

 So I don't understand how to send IP-ID random value ...

 Perhaps you think of the ipv4_innermost_irregular{} method, page 63, but I don't understand how to use this method and the compressed format co_common{} ...

 And I don't have any samples or reference captures file : only the RFC text!

 Thank you for your help and explanation.

 Best regards,

              FWX.

Le 05/03/2012 09:39, Carl Knutsson a écrit :

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.

_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www.ietf.org/mailman/listinfo/rohc