[rohc] Regarding the TCP Options in the IR, IR-DYN Packets

Anil Maguluri <Anil.Maguluri@lntinfotech.com> Wed, 21 April 2010 12:12 UTC

From: Anil Maguluri <Anil.Maguluri@lntinfotech.com>
To: "rohc@ietf.org" <rohc@ietf.org>
Date: Wed, 21 Apr 2010 17:40:43 +0530
Thread-Topic: Regarding the TCP Options in the IR, IR-DYN Packets
Thread-Index: AcrhS6qhsSd7yu84QrqUD+qQ5xBd8A==
Message-ID: <C7232BDB534C6241BE85C96D129205D002F4223601@BLRINMSMBX01.bglrodc.lntinfotech.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7232BDB534C6241BE85C96D129205D002F4223601BLRINMSMBX01b_"
MIME-Version: 1.0
Cc: Anil Kumar Maguluri <anilmaguluri@gmail.com>
Subject: [rohc] Regarding the TCP Options in the IR, IR-DYN Packets
Precedence: list

Hi All,

Please clarify me whether my understanding is correct or not regarding
to identify the TCP Options in the IR/IR-DYN Packets.
We don't have any fields which informs the presence of TCP Options in
IR/IR-DYN Packets.

I thought of two methods to identify the above. Please let me know
which method we should follow, otherwise IOT will fail.

Method-1:
Compressor should encode at least one byte for TCP Options in TCP
Dynamic Chain even if the TCP Options are not present in the received
packet.
If Compressor not received TCP Options in the received packet, it can encode
one byte of TCP Option field in TCP Dynamic chain with value 0x00. Otherwise
Compressor will use List Compression encoding method to encode the
TCP Option field in the TCP Dynamic Chain.

The Decompressor will be checking TCP Option byte to continue the IR/IR-DYN
Packet decoding. If the TCP Option byte value is 0x00, then Decompressor
can stop decoding the packet and validate the CRC of the received packets.

Method-2:
Compressor will encode TCP Option field only if the received packet
has TCP Options. It is very difficult to identify the TCP Options are present or
not at the decompressor in this method.

I thought of two approaches to solve the above at the decompressor.
Approch-1:
Decompressor should process the TCP Option byte assuming the TCP options
are present at the TCP Dynamic Chain. This approach is complicated.

Step-1: Decompressor will decode the first byte of the TCP option field,
and verify the Reserved bits (should be zero) otherwise assume TCP options
are not present.

Step-2: If the reserved bits are verified, check value of "m", assume that many
items are present in the received packet. Then start checking the XI values,
and verify the index value is less than 16. If any index is more than 15, then
assume TCP Options are not present, otherwise continue the packet processing.

Step-3: Parse each item, check the option type, length and index, whether option
type-index mapping is correct or not as per the RFC. If everything is fine, then
assume TCP Options are present, otherwise assume not present.

Approch-2:
Decompressor should assume no TCP Options are received in the received
TCP Dynamic chain of IR/IR-DYN packets and decode the packet.
Then, calculate the CRC and validate the CRC. If CRC fails, then assume TCP
options are present in the received packet then start processing as per the
Approch-1, then validate the CRC.

Thanks for your support.

Regards,
Anil Kumar Maguluri

________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________

[rohc] Regarding the TCP Options in the IR, IR-DY… bugz.ray
[rohc] Regarding the TCP Options in the IR, IR-DY… Anil Maguluri