Subject: [rohc] RFC4996 IP-ID with co_common and Random behavior

From: RoHC Team <[email-masked]>
Date: Mon, 27 Feb 2012 17:02:57 +0100

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 ?

  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.

  Thanks for help,

  Best regards
                    FWX.

---

From: Carl Knutsson <[email-masked]>
Date: Mon, 05 Mar 2012 09:39:06 +0100

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.
> 

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

>       about which fields are present in the header format.

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

---

From: RoHC Team <[email-masked]>
Date: Mon, 05 Mar 2012 10:59:03 +0100

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 {

  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.

---

From: Raffles <[email-masked]>
Date: Mon, 05 Mar 2012 23:02:21 +0000

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@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 {

}

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!

Best regards,

FWX.

Hi,

Comment inline.

Cheers

/Calle

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_indicator

ip_id_behavior

ip_id_indicator.CVALUE)

with :

{

UNCOMPRESSED {

ip_id [ 16 ];

}

COMPRESSED short {

(behavior ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));

ENFORCE(indicator == 0);

}

COMPRESSED long {

(behavior ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));

ENFORCE(indicator == 1);

}

COMPRESSED not_present {

}

}

So, if ip_id_behavior is RANDOM, ip_id is not compressed
(not present)

Why not ip_id =:= irregular(16)  [ 16 ]; when behavior is
RANDOM ?

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

_______________________________________________

Rohc mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/rohc

--

Raffles (Robert Finking)
m: 0789 463 9887
e: [email-masked]
w: gluft.com

O O
OOOOOO O O O OOOOOO OOOOO
O O O O O OOOOO O
OOOOOO O OOOOOO O O
OOOOOO
we care about software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336 VAT No.: 974 2755 83
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.

Please consider the environment before printing. Thank you.
-----------------------------------------------------------------