Subject: [rohc] Question about NORMAL_PACKET in RFC 3095

From: [email-masked]
Date: Tue, 15 Oct 2002 16:35:39 +0200

Hi,

I have a question about a problem that I encountered during the 
implementation of RoHC. I am implementing RoHC profiles 0x00 
(uncompressed) and 0x01 (IP/UDP/RTP). 

At the decompressor I check which type of packet is coming in. But I 
discovered that the decompressor can be wrong in its decision when the 
following happens:

If a UO_0 packet has CID = 0 then this CID and the ADD_CID are skipped 
thus the packet starts with: 0 - SN - CRC  and then the payload.

But it turned out that it is possible that the value of the first 4 bit's 
is 0x4 and also that the value of the first byte is 0x45 and this is the 
problem. Because when a NORMAL packet within UNCOMPRESSED profile with CID 
= 0 is used, then the first byte is also 0x45 (in case of IPv4). Therefore 
the decompressor assumes that my UO_0 packet is a NORMAL packet, but this 
again conflicts with the RTP-profile in the decompressor context and it 
thinks the packet is corrupted and the packet is discarded.

In section 5.10.2 of RFC 3095 is stated for a NORMAL packet in 
UNCOMPRESSED profile that: 
"Note that the first octet of the IP packet starts with the bit pattern 
0100 (IPv4) or 0110 (IPv6). This does not conflict with any reserved 
packet types. Hence, no bits in addition to the CID are needed. The 
profile is reasonably future-proof since problems do not occur until IP 
version 14. "

The solution I have in mind is, to check the next bits/byte of the packet 
also in case it might be a NORMAL packet. If the first byte is 0x45 and if 
the second byte is 0x00 then the incoming packet is with a (very) high 
probability a NORMAL packet. Because the Differentiated fields of a IP 
packet are most of the time 0x00. Otherwise this would mean that the 
payload of the UO_0 packet would start with 0x00 AND that the UO_0 packet 
started with 0x45, this probability is neglectable I think.

Did anybody else maybe have the same problem or may be that there is 
already another solution for this problem.

Any comment is welcome.

Regards,

Ralph Maassen

---

From: "Mikael Degermark" <[email-masked]>
Date: Tue, 15 Oct 2002 15:56:06 -0700

Ralph, 

You have given a situation that can not occur: that CID 0 is BOTH profile 0 and profile 1.

As long as there is at most one profile per CID, there is no possibility of confusion.
Please check again. 

Micke

----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked]' 
  Cc: [email-masked] 
  Sent: Tuesday, October 15, 2002 7:35 AM
  Subject: [rohc] Question about NORMAL_PACKET in RFC 3095

  Hi, 

  I have a question about a problem that I encountered during the implementation of RoHC. I am implementing RoHC profiles 0x00 (uncompressed) and 0x01 (IP/UDP/RTP). 

  At the decompressor I check which type of packet is coming in. But I discovered that the decompressor can be wrong in its decision when the following happens: 

  If a UO_0 packet has CID = 0 then this CID and the ADD_CID are skipped thus the packet starts with: 0 - SN - CRC  and then the payload. 

  But it turned out that it is possible that the value of the first 4 bit's is 0x4 and also that the value of the first byte is 0x45 and this is the problem. Because when a NORMAL packet within UNCOMPRESSED profile with CID = 0 is used, then the first byte is also 0x45 (in case of IPv4). Therefore the decompressor assumes that my UO_0 packet is a NORMAL packet, but this again conflicts with the RTP-profile in the decompressor context and it thinks the packet is corrupted and the packet is discarded. 

  In section 5.10.2 of RFC 3095 is stated for a NORMAL packet in UNCOMPRESSED profile that: 
  "Note that the first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any reserved packet types. Hence, no bits in addition to the CID are needed. The profile is reasonably future-proof since problems do not occur until IP version 14. " 

  The solution I have in mind is, to check the next bits/byte of the packet also in case it might be a NORMAL packet. If the first byte is 0x45 and if the second byte is 0x00 then the incoming packet is with a (very) high probability a NORMAL packet. Because the Differentiated fields of a IP packet are most of the time 0x00. Otherwise this would mean that the payload of the UO_0 packet would start with 0x00 AND that the UO_0 packet started with 0x45, this probability is neglectable I think. 

  Did anybody else maybe have the same problem or may be that there is already another solution for this problem. 

  Any comment is welcome. 

  Regards, 

  Ralph Maassen