Regarding the TCP Options in the IR, IR-DYN Packets
Anil Maguluri <[email protected]> Wed, 21 Apr 2010 17:40:43 +0530
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <C7232BDB534C6241BE85C96D129205D002F4223601@BLRINMSMBX01.bglrodc.lntinfotech.com> |
--===============1109309974==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_C7232BDB534C6241BE85C96D129205D002F4223601BLRINMSMBX01b_"
--_000_C7232BDB534C6241BE85C96D129205D002F4223601BLRINMSMBX01b_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 enco=
de
one byte of TCP Option field in TCP Dynamic chain with value 0x00. Otherwi=
se
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-DY=
N
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 pres=
ent 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 value=
s,
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 processi=
ng.
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 TC=
P
options are present in the received packet then start processing as per th=
e
Approch-1, then validate the CRC.
Thanks for your support.
Regards,
Anil Kumar Maguluri
________________________________
This Email may contain confidential or privileged information for the inte=
nded recipient (s) If you are not the intended recipient, please do not us=
e or disseminate the information, notify the sender and delete it from you=
r system.
______________________________________________________________________
--_000_C7232BDB534C6241BE85C96D129205D002F4223601BLRINMSMBX01b_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-mic=
rosoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"ht=
tp://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii=
">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
=09{font-family:Calibri;
=09panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0in;
=09margin-bottom:.0001pt;
=09font-size:11.0pt;
=09font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
=09{mso-style-priority:99;
=09color:blue;
=09text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
=09{mso-style-priority:99;
=09color:purple;
=09text-decoration:underline;}
span.EmailStyle17
=09{mso-style-type:personal-compose;
=09font-family:"Calibri","sans-serif";
=09color:windowtext;}
.MsoChpDefault
=09{mso-style-type:export-only;}
@page Section1
=09{size:8.5in 11.0in;
=09margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
=09{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal">Hi All,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Please clarify me whether my understanding is corre=
ct or not regarding
<o:p></o:p></p>
<p class=3D"MsoNormal">to identify the TCP Options in the IR/IR-DYN Packet=
s. <o:p></o:p></p>
<p class=3D"MsoNormal">We don’t have any fields which informs the pr=
esence of TCP Options in
<o:p></o:p></p>
<p class=3D"MsoNormal">IR/IR-DYN Packets.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I thought of two methods to identify the above. Ple=
ase let me know<o:p></o:p></p>
<p class=3D"MsoNormal">which method we should follow, otherwise IOT will f=
ail.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Method-1:<o:p></o:p></p>
<p class=3D"MsoNormal">Compressor should encode at least one byte for TCP =
Options in TCP
<o:p></o:p></p>
<p class=3D"MsoNormal">Dynamic Chain even if the TCP Options are not prese=
nt in the received<o:p></o:p></p>
<p class=3D"MsoNormal">packet.<o:p></o:p></p>
<p class=3D"MsoNormal">If Compressor not received TCP Options in the recei=
ved packet, it can encode
<o:p></o:p></p>
<p class=3D"MsoNormal">one byte of TCP Option field in TCP Dynamic chain w=
ith value 0x00. Otherwise<o:p></o:p></p>
<p class=3D"MsoNormal">Compressor will use List Compression encoding metho=
d to encode the<o:p></o:p></p>
<p class=3D"MsoNormal">TCP Option field in the TCP Dynamic Chain.<o:p></o:=
p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">The Decompressor will be checking TCP Option byte t=
o continue the IR/IR-DYN<o:p></o:p></p>
<p class=3D"MsoNormal">Packet decoding. If the TCP Option byte value is 0x=
00, then Decompressor<o:p></o:p></p>
<p class=3D"MsoNormal">can stop decoding the packet and validate the CRC o=
f the received packets.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Method-2:<o:p></o:p></p>
<p class=3D"MsoNormal">Compressor will encode TCP Option field only if the=
received packet<o:p></o:p></p>
<p class=3D"MsoNormal">has TCP Options. It is very difficult to identify t=
he TCP Options are present or<o:p></o:p></p>
<p class=3D"MsoNormal">not at the decompressor in this method.<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">I thought of two approaches to solve the above at t=
he decompressor.<o:p></o:p></p>
<p class=3D"MsoNormal">Approch-1:<o:p></o:p></p>
<p class=3D"MsoNormal">Decompressor should process the TCP Option byte ass=
uming the TCP options<o:p></o:p></p>
<p class=3D"MsoNormal">are present at the TCP Dynamic Chain. This approach=
is complicated.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Step-1: Decompressor will decode the first byte of =
the TCP option field,<o:p></o:p></p>
<p class=3D"MsoNormal">and verify the Reserved bits (should be zero) other=
wise assume TCP options<o:p></o:p></p>
<p class=3D"MsoNormal">are not present.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Step-2: If the reserved bits are verified, check va=
lue of “m”, assume that many<o:p></o:p></p>
<p class=3D"MsoNormal">items are present in the received packet. Then star=
t checking the XI values,<o:p></o:p></p>
<p class=3D"MsoNormal">and verify the index value is less than 16. If any =
index is more than 15, then<o:p></o:p></p>
<p class=3D"MsoNormal">assume TCP Options are not present, otherwise conti=
nue the packet processing.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Step-3: Parse each item, check the option type, len=
gth and index, whether option<o:p></o:p></p>
<p class=3D"MsoNormal">type-index mapping is correct or not as per the RFC=
. If everything is fine, then
<o:p></o:p></p>
<p class=3D"MsoNormal">assume TCP Options are present, otherwise assume no=
t present.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Approch-2:<o:p></o:p></p>
<p class=3D"MsoNormal">Decompressor should assume no TCP Options are recei=
ved in the received<o:p></o:p></p>
<p class=3D"MsoNormal">TCP Dynamic chain of IR/IR-DYN packets and decode t=
he packet.<o:p></o:p></p>
<p class=3D"MsoNormal">Then, calculate the CRC and validate the CRC. If CR=
C fails, then assume TCP<o:p></o:p></p>
<p class=3D"MsoNormal">options are present in the received packet then sta=
rt processing as per the<o:p></o:p></p>
<p class=3D"MsoNormal">Approch-1, then validate the CRC.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Thanks for your support.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Anil Kumar Maguluri<o:p></o:p></p>
</div>
<br>
<hr>
<font face=3D"Arial" color=3D"Black" size=3D"3">This Email may contain con=
fidential or privileged information for the intended recipient (s) If you =
are not the intended recipient, please do not use or disseminate the infor=
mation, notify the sender and delete it from
your system.<br>
</font>
<BR>
______________________________________________________________________<BR>=
</body>
</html>
--_000_C7232BDB534C6241BE85C96D129205D002F4223601BLRINMSMBX01b_--
--===============1109309974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc
--===============1109309974==--