ROHC-FN and TCP Profile - Version 3

Hi Yousuf and others,

We've updated our implementation to print out a list of the
TCP/IP packet formats. A copy is available at:

http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_3.zip

Just type "build(n)." where n = 0, 1 or 2 depending on how much
information you'd like to be displayed:

n = 0: Prints the 'core' packet formats only, excluding any fields
       compressed using list encoding (such as the TCP options).
n = 1: Prints the packet formats in full, including any fields
       compressed using list encoding.
n = 2: Prints all packet formats. If a variable-length compressed
       field is encountered, the formula for calculating its length
       is also displayed.

The results are saved in the file "output.txt" for later reference.

As an example, Packet Format 0 (the simplest one) is as follows:

Packet Format 0:

   discriminator:        00
   header_crc:           3 bits
   master_seq_number:    2 bits
   tcp_psh_flag:         1 bit
   tcp_checksum:         16 bits

Ip routing in rohc..

Hi all.
      In the ROHC the headers are compressed and the ip address is not in
the compressed headers as far as i know. Since the header doesnt have any
info about the ip address, how the packets are routed. Thanks in advance..
Brgds
Shanmugasundaram.M
CGM

**********************************************************************************
Confidentiality Information & Notice:

Information contained and transmitted in this E-MAIL and its attachment(s)
is proprietary to CG Maersk Technologies and is for the sole use of the
intended recipient(s) and may contain information that is privileged,
confidential or exempt from disclosure under applicable law. If you are not
the intended recipient, you are notified that any use, distribution,
transmission, forwarding, printing, copying or dissemination of this
information in any way or in any manner is strictly prohibited. If you have
received this email in error, please delete this email and inform us at
emailerror <at> cgmaersk.com.
**********************************************************************************

Re: Ip routing in rohc..

Hi
    ROHC compression/decompression is done on a per-hop basis. So ROHC 
packets will be compressed at post-routing stage and decompressed at 
pre-routing stage. When I say post-routing, I mean that the next hop has 
been detected from the forwarding table and pre-routing means as soon as 
the packet gets off the wire.

Cheers
Kausik

sha <at> cgmaersk.com wrote:

>Hi all.
>      In the ROHC the headers are compressed and the ip address is not in
>the compressed headers as far as i know. Since the header doesnt have any
>info about the ip address, how the packets are routed. Thanks in advance..
>Brgds
>Shanmugasundaram.M
>CGM
>
>
>
>**********************************************************************************
>Confidentiality Information & Notice:
>
>Information contained and transmitted in this E-MAIL and its attachment(s)
>is proprietary to CG Maersk Technologies and is for the sole use of the
>intended recipient(s) and may contain information that is privileged,
>confidential or exempt from disclosure under applicable law. If you are not
>the intended recipient, you are notified that any use, distribution,

RE: ROHC-FN and TCP Profile - Version 3

Hi William,

 

The FIELD(n) encoding method takes the next n bits from the

uncompressed header and stores them in a temporary variable

called Field_Value.  The NEXT_FIELD encoding method works

in a similar manner, but rather than taking the bits from the

uncompressed header, it takes them from a labelled field instead.

 

As you spotted in the TCP/IP profile, it's possible to encounter

an instance of NEXT_FIELD immediately followed by an instance

of FIELD(n).  In this case the NEXT_FIELD encoding method is

considered to "win" - i.e. the Field_Value is taken from the

labelled field rather than from the uncompressed header.  We

can see that this is the case from the following pseudocode, taken

from the definition of FIELD(n):

 

   If Field_Value == Null then set Field_Value:= F and set 
   Remaining_Data := Remaining_Data - n.

So, the FIELD(n) encoding method must first check whether

the Field_Value temporary variable already contains a field value

or not.  If it doesn't then the next n bits are extracted from the

uncompressed header as expected.  However, if the NEXT_FIELD

encoding method has been used previously, then Field_Value

will already be set and the FIELD(n) encoding method will be

ignored.

 

This behaviour is a little clumsy, so why do we need it?  The

benefit is that we can compress labelled fields using ordinary

encoding methods such as STATIC and IRREGULAR, e.g:

 

                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

 

As you pointed out, the STATIC and IRREGULAR encoding

methods both call an instance of FIELD(n) to extract some

bits from the uncompressed header.  Using the NEXT_FIELD

encoding method we can "override" this default behaviour and

force them to compress a labelled field instead.

 

If you can think of a neater way of doing this then please let

me know

 

Regards,

 

Richard

-----Original Message-----
From: william zheng [mailto:zheng_william <at> hotmail.com]
Sent: Friday, May 09, 2003 3:40 AM
To: Price, Richard
Subject: Re: [rohc] ROHC-FN and TCP Profile - Version 3

Hi, Richard,

I am confused on the definition of FIELD and NEXT_FIELD.

According to ROHC-FN draft, FIELD encoding method extracts an n-bit field from the uncompressed packet and stores it in a temporary variable. It means this encoding method operates on the header rather than any label or temporary varialbe. NEXT_FIELD instead operates on labeled field. See the example where NEXT_FIELD is used as follows. 

tcp_options           -->   list(data_offset,1,32,-160,
                             [optional(tcp_sack),
                              optional(tcp_timestamp),
                              optional(tcp_end),
                              optional(tcp_no_operation),
                              optional(tcp_no_operation),
                              optional(tcp_generic),
                              optional(tcp_generic),
                              optional(tcp_generic)])++
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

The encoding method that follows the next_field is either STATIC or IRREGULAR, both further using FIELD encoding method via RANGE. It seems quite difficult to understand we can use FIELD encoding method when a labeled field is expected to be encoded/decoded. Consider that following next_field(order)++ we expect to add the labeled field 'order' to the compressed header, but when we use static or irregular(24), we point to the uncompressed header and try to shift the 'remaining_data'. But this is not the action we want to take, is it right?

Thanks.

RGDS,

William 

The new MSN 8: smart spam protection and 2 months FREE*

linux constant IP ID field can't be compressed in profile 0x0001?

Is there an obvious way to solve the problem of the constant value
of the IP header Identifier field for UDP/IP from linux boxes?
As I read it, RFC 3095, 5.7, p.75, says that the difference of the
IP-ID minus the RTP is encoded with p = 0, which means that the _difference_
may be constant or slowly increasing.

Therefore as I understand it, an IP ID field which is always equal to
zero is incompressible.
Can this be right? If so, this is a black mark against linux.

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
    city: Adelaide, South Australia
  coords: 34.88051 S, 138.59334 E
timezone: UTC+0930 http://topology.org/timezone.html
 company: Topoz Pty Ltd
 website: http://topoz.net/

RE: linux constant IP ID field can't be compressed in profile 0x0001?

> Is there an obvious way to solve the problem of the constant value
> of the IP header Identifier field for UDP/IP from linux boxes?

Constant IP-ID?? It looks to me a faulty implementation (of IP stack)
which defeats the exact purpose of IP-ID (see RFC 791).

BR,
Zhigang

IP-only profile feedback

We are a group of students that have been working with implementing ROHC during 
the spring semester, in a project course at Luleå University of Technology. 
We have almost finished the course and have some comments for the ROHC working 
group. 

 
IP-only draft feedback. 

 
The draft is mainly well written and easy to follow. We have not implemented any 
support for more than two ip-headers so we have no experience of implementing that 
part. However we have some feedback on that part. One thing is that if one of these 
ip-headers looses its static part, then the compressor have to go down to IR-state 
which will lead to quite much overhead. The reason for this is that it has to 
send all the headers dynamic and static parts. We have a suggestion of how this 
could be improved below, where we also have a sugesstion of how the problem with 
IP-ID = 0 could be solved. IP-ID should not be zero, but we have detected that it 
is zero when sending package in a local network. The condition is that both the 
source and destination are members in the same submask-network. The DF-flag is 
also set in the package. Even if this behavior seems to be odd, all the packages 
is correct accoriding to the standard. This have been found in the Linux 
implementation (kernel 2.4.20). Other OS may have the same "problem". 

 
Problem solving suggestions: 

Multiple ip-headers: 

For all extra (more than two) ip-headers where you send only the dynamic part in 
a normal packet you can speculate in how often the static part will be changed. 
If this often is the case the compressor often have to send IR-packets. To not 
have to send this overhead, you could have an extra flag that says that if this 
flag is set for that specific IP-header then the static part for that header 
alsow will be in the packet. (After all dynamic fields?) 

Dynamic part: 

   +---+---+---+---+---+---+---+---+ 
   |        Type of Service        | 
   +---+---+---+---+---+---+---+---+ 
   |         Time to Live          | 
   +---+---+---+---+---+---+---+---+ 
   /        Identification         /   2 octets 
   +---+---+---+---+---+---+---+---+ 
   | DF|RND|NBO| - | 0 | SC| 0 | 0 | 
   +---+---+---+---+---+---+---+---+ 
   / Generic extension header list /  variable length 
   +---+---+---+---+---+---+---+---+ 

SC = Static Chain (is included) 

 
IP-ID == 0: 

One solution on the IP-ID equal to zero problem is to add a flag (SID) that says 
if the ID-field is static. 

Dynamic part: 

   +---+---+---+---+---+---+---+---+ 
   |        Type of Service        | 
   +---+---+---+---+---+---+---+---+ 
   |         Time to Live          | 
   +---+---+---+---+---+---+---+---+ 
   /        Identification         /   2 octets 
   +---+---+---+---+---+---+---+---+ 
   | DF|RND|NBO|SID| 0 | - | 0 | 0 | 
   +---+---+---+---+---+---+---+---+ 
   / Generic extension header list /  variable length 
   +---+---+---+---+---+---+---+---+ 

SID = Static Identification 

Re: linux constant IP ID field can't be compressed in profile 0x0001?

> > Is there an obvious way to solve the problem of the constant value
> > of the IP header Identifier field for UDP/IP from linux boxes?
> 
> Constant IP-ID?? It looks to me a faulty implementation (of IP stack)
> which defeats the exact purpose of IP-ID (see RFC 791).
> 
I had faced the same problem earlier (check list archives). Since the
Linux stack behaviour is non standard, I guess its upto the Linux guys
to fix it.

- Sukanta

RE: IP-only profile feedback

Hi Fredrik,

Comments inline....

> The draft is mainly well written and easy to follow. We have 
> not implemented any  support for more than two ip-headers so
> we have no experience of implementing that part. However we
> have some feedback on that part. One thing is that if one of
> these ip-headers looses its static part, then the compressor
> have to go down to IR-state which will lead to quite much
> overhead. The reason for this is that it has to send all the
> headers dynamic and static parts. 

Well, if the static part changes, it is actually a new stream
and it might be better to set up a new context.

> IP-ID should not be zero, but we  have detected that it 
> is zero when sending package in a local network. The
> condition is that both the source and destination are
> members in the same submask-network. The DF-flag is 
> also set in the package. Even if this behavior seems to be 
> odd, all the packages is correct according to the standard.
> This have been found in the Linux implementation
> (kernel 2.4.20). Other OS may have the same "problem".

Thanks for clarifying this. It is thus not really an invalid
stack implementation, but it is indeed a little bit odd.
However, this should not be a big problem for scenarios where
ROHC would actually be implemented, right? It is more of
a typical "test environment problem".

> Problem solving suggestions: 
>  
> Multiple ip-headers: 
>  
> For all extra (more than two) ip-headers where you send only 
> the dynamic part in a normal packet you can speculate in how
> often the static part will be changed. If this often is the
> case the compressor often have to send IR-packets. To not 
> have to send this overhead, you could have an extra flag that 
> says that if this flag is set for that specific IP-header
> then the static part for that header also will be in the
> packet. (After all dynamic fields?) 
>  
> Dynamic part: 
>  
>    +---+---+---+---+---+---+---+---+ 
>    |        Type of Service        | 
>    +---+---+---+---+---+---+---+---+ 
>    |         Time to Live          | 
>    +---+---+---+---+---+---+---+---+ 
>    /        Identification         /   2 octets 
>    +---+---+---+---+---+---+---+---+ 
>    | DF|RND|NBO| - | 0 | SC| 0 | 0 | 
>    +---+---+---+---+---+---+---+---+ 
>    / Generic extension header list /  variable length 
>    +---+---+---+---+---+---+---+---+ 
>  
> SC = Static Chain (is included) 

As I said above, I think this is one of those corner-cases
we should not have to worry about. Anyway, your solution
might be neat, but it is only applicable for IPv4, as you
do not have these spare bits in the IPv6 dynamic chain.

> IP-ID == 0: 
>  
> One solution on the IP-ID equal to zero problem is to add a 
> flag (SID) that says 
> if the ID-field is static. 
>  
> Dynamic part: 
>  
>    +---+---+---+---+---+---+---+---+ 
>    |        Type of Service        | 
>    +---+---+---+---+---+---+---+---+ 
>    |         Time to Live          | 
>    +---+---+---+---+---+---+---+---+ 
>    /        Identification         /   2 octets 
>    +---+---+---+---+---+---+---+---+ 
>    | DF|RND|NBO|SID| 0 | - | 0 | 0 | 
>    +---+---+---+---+---+---+---+---+ 
>    / Generic extension header list /  variable length 
>    +---+---+---+---+---+---+---+---+ 
>  
> SID = Static Identification 

This could actually be done as proposed, since it is an
IPv4-only problem. However, it does change the standard so
it would require a profile update for already existing
profiles. Anyway, we can of course include it in the IP
profile, that is probably a good idea. Let's just see if
there are any more opinions about that.

Cheers,
/L-E

RE: IP-only profile feedback

I guess I better correct myself on this statement:

> Thanks for clarifying this. It is thus not really an invalid
> stack implementation, but it is indeed a little bit odd.

Actually, it can probably be considered an incorrect
implementation as it would not comply with the rule of
RFC 791:
"Thus, the sender must choose the Identifier to be unique
for the source, destination pair and protocol for the time
the datagram (or any fragment of it) could be alive in the
internet."

However, if one considers the purpose of the Identification
field and the intent with the above text (i.e. the above is
an obvious consequence of how fragmentation/reassembly is
defined), one could claim that the Identification is not
used if DF is set, and that the above text would not apply
in that case.

Anyway, for us this is not a very big problem. We might want
to make ROHC handle this case better, but I do not think
it is a core issue. Neither should we waste our time trying
to agree on whether there is a Linux error or not.

/L-E