Subject: [rohc] ROHC-TCP and EPIC-LITE

From: "zheng_william" <[email-masked]>
Date: Wed, 6 Nov 2002 13:58:30 +0800

Hi, all,

Is anyone interested in implementation of ROHC-TCP with EPIC-LITE as coding framework?

I happen to have a question about splitting the compressed header packet into compressed header and the payload before decompressing the fields (procedure  READ-FLAGS, P. 54-56 in 'Framework for EPIC-LITE'). As LIST encoding method is used in ROHC-TCP (P. 39, draft-ietf-rohc-tcp-02.txt), the compressed bits length may be unable to decide (e.g OPTIONAL encoding method is used, see the example as follows,
tcp-options-co = ROTATE(3,1);
                        LIST (4,1,32,-160,8, U(OPTIONAL(tcp-sack-co), ...). 
Therefore, the compressed header length may be unavailable through calling the function get-header-length (the precodure READ-FLAGS, P. 56, 'Framework for EPIC-LITE'). Is it right? 

BR,
William

---

From: Julije Ozegovic <[email-masked]>
Date: Thu, 07 Nov 2002 11:32:42 +0100

Hi William,

here at University of Split, Croatia, we have a running 
implementation of EPIC-Lite, in accordance with Framework for 
EPIC-LITE, draft-ietf-rohc-epic-lite-01.txt, February 2002.

The interoperability tests with Roke Manor (original inventors) 
are successfully passed for TCP/IP and RTP/UDP/IP test profiles. 
Tests were performed using seven TCP and eleven RTP test streams.

Current implementation will soon be available for public use 
under open licence, involving file-to-file compression and 
decompression for Windows and Linux, and communicating (on-line) 
version for Linux. Interoperability test results will be 
published as well.

Also, experimental results and experience are publisihed at 
SoftCOM 2002 conference special session on header compression. 
Papers will be available under IEEE licence.

Now about your question. The format of EPIC-lite frame is as 
follows:

+---------+--------------+--+-----------+--+----------------+
|ID_bits  |Compr. header |P1|UNC_fields |P2|Payload         |
+---------+--------------+--+-----------+--+----------------+

UNC_fields is accssed (assuming U method is used) field by field 
using data from PRESENCE and ORDER fields located in Compressed 
header (after LIST). So it is true that Payload position is not 
known apriori, but is well known after the Compressed header 
processing. We just advance UNC_fields read pointer and consider 
Payload starting at next byte boundary. The same mechanism is 
used for UNCOMPRESSED method.

NOTE: While padding P1 is covered in draft, padding P2 is not, 
so we just fill it with zeroes at the compressor, and ignore it 
in decompressor.

Best regards,
Julije Ozegovic

---------------------------
Julije Ozegovic, PhD
University of Split
FESB Split
R.Boskovica bb
Croatia
tel.++385 21 305725
mailto:[email-masked]
http://www.fesb.hr/~julije
---------------------------

zheng_william wrote:
> I happen to have a question about splitting the compressed header packet 
> into compressed header and the payload before decompressing the fields 
> (procedure  READ-FLAGS, P. 54-56 in 'Framework for EPIC-LITE'). As LIST 
> encoding method is used in ROHC-TCP (P. 39, draft-ietf-rohc-tcp-02.txt), 
> the compressed bits length may be unable to decide (e.g OPTIONAL 
> encoding method is used, see the example as follows,
> Therefore, the compressed header length may be unavailable through 
> calling the function get-header-length (the precodure READ-FLAGS, P. 56, 
> 'Framework for EPIC-LITE'). Is it right? 
>  
> BR,
> William
>  
>  

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc