Subject: [rohc] ROHC-TCP packet formats - chain definitions

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 04 Oct 2004 10:43:02 +0200

Hi all,

now with a hopefully more stable FN, we need to start looking at the packet 
formats for ROHC-TCP. Issues we had in the latest version needs to be agreed on, 
so I'll list some of them here with proposed solutions.

- Chain concept. We've agreed on how the static/dynamic/replicate/irregular 
chains should work, but we've seen a number of different attempts to express 
them in FN, and I don't think they have really made sense from a reader's 
perspective. The latest attempt was to use things like let (previous 
(next_header):uncomp_value == 60);
Since parseability is not a requirment, I think that the entire chain concept 
should just be expressed in English, and let the implementer assemble the chains 
as he sees fit. In 6.5.1, 6.5.2 and 6.5.3, we already have ASCII-pictures of all 
  the usages of chains, so we should just expand the "profile specific part" to 
show which chains are present in this packet and describe how the chains are 
built. (by the way, it is anyway kind of silly to talk about profile specific 
part in a document defining only one sigle profile)

- Innermost IP header. Expressing this in FN has turned out to be somewhat 
challenging, while it is really intuitive in english. First, we tried to use 
about the same thing as for the dynamic/static chains, but realized that the 
innermost IP header can be followed by extension headers before the TCP header, 
so this would require some form of state-keeping, which is unsutable in FN. So, 
we should skip how this is "parsed" and just express it in a simple way. The 
only reason we need to know if it is an innermost header is for the irregular 
chain (IP-ID is considered random for all but innermost header). So, we could 
easily make one item ipv4_irregular_innermost and ipv4_irregular_outer and 
describe in english when each one should be used.

Some suggested text for next TCP profile version (off the top of my head so the 
exact wording can be worked out later):
All section references refer to the -07 revision
******************************************

6.5.1.1 (the current 6.5.1, but split the "profile specific part" into static 
and dynamic chain in the picture)
6.5.1.2 Constructing Static and Dynamic Chains

The static chain is constructed by taking the part of a header named with a 
_static prefix for each header in the uncompressed packet. The first item in the 
chain should be taken from the header appearing first in the chain and the last 
item should be taken from a TCP header.

For example:
If a packet containing IPv6/IP6routing/IPv4/TCP is compressed to an IR packet, 
the static chain should be constructed by concatenating format_ipv6_static, 
format_route_opt_static, format_ipv4_static, format_tcp_static from these headers.

The dynamic chain is constructed analogously as the static chain.

6.5.2.1 (the current 6.5.2, but replace the "profile specific part" with 
"Replicate Chain")
6.5.2.2 Constructing the Replicate Chain

The replicate chain in the IR-CR packet is constructed analogously to the static 
and dynamic chains described in 6.5.1.1 so that one item in the replicate chain 
is taken from each header in the uncompressed packet. It should be noted that 
there are often multiple different replicate chain items to choose from for each 
header. The choice of which to use is an implementation issue based on the 
replicate strategy of the compressor.

6.5.3.1 (the current 6.5.3)
6.5.3.2 Constructing the Header Chain Irregular Part

The irregular chain of all compressed packet formats is constructed analogously 
to the static and dynamic chains described in 6.5.1.2 so that one item in the 
irregular chain is taken from each header in the uncompressed packet. There is 
one additional concept that the compressor needs to notice though. Since the 
innermost IP header is part of the base header, the innermost IP header has a 
different irregular chain than all other IP headers. Therefore, both the IPv4 
header and the IPv6 header has two different irregular chain items, where one is 
prefixed by innermost_ and the other is prefixed outer_. The compressor should 
only choose the _innermost item if there are no more IP headers between this 
header and the TCP header.

6.5.3.3 TCP Options Irregular Part

Apart from the Header Chain Irregular Part, the TCP Options Irregular Part is 
also included in the general format for a compressed TCP header. This field 
should be constructed by taking an item postfixed by _irregular for each TCP 
option present in the uncompressed packet in the order that they appear. For 
example:

The TCP options list contains NOP, NOP and EOL options. Then the TCP Options 
Irregular Part is constructed from format_nop_irregular, format_nop_irregular 
and format_eol_irregular.

*********************************************

This would mean that we remove sections 6.6.7-6.6.10 in -07, which I think makes 
sense since all this stuff with "previous" etc is only useful from a parsing 
perspective, while I find it only confusing from an implementer's perspective.

I can probably try to make a revised version of the packet formats later this 
week if this is the way we decide to go.

Let the flaming begin.

/Kristofer Sandlund, Effnet AB

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 4 Oct 2004 11:09:19 +0200

> - Chain concept. We've agreed on how the
> static/dynamic/replicate/irregular chains should work,
> but we've seen a number of different attempts to express 
> them in FN, and I don't think they have really made
> sense from a reader's perspective. Since parseability is
> not a requirment, I think that the entire chain concept 
> should just be expressed in English, and let the
> implementer assemble the chains as he sees fit.

Fully agree!

> In 6.5.1, 6.5.2 and 6.5.3, we already have ASCII-pictures
> of all the usages of chains, so we should just expand the
> "profile specific part" to show which chains are present
> in this packet and describe how the chains are built.
> (by the way, it is anyway kind of silly to talk about 
> profile specific part in a document defining only one
> sigle profile)

Yes, that is a good point, let's fix that terminology.

> - Innermost IP header. Expressing this in FN has turned
> out to be somewhat challenging, while it is really'
> intuitive in english. First, we tried to use about the
> same thing as for the dynamic/static chains, but realized
> that the innermost IP header can be followed by extension
> headers before the TCP header, so this would require some
> form of state-keeping, which is unsutable in FN. So, we
> should skip how this is "parsed" and just express it in a 
> simple way. The only reason we need to know if it is an
> innermost header is for the irregular chain (IP-ID is
> considered random for all but innermost header). So, we
> could easily make one item ipv4_irregular_innermost and 
> ipv4_irregular_outer and describe in english when each
> one should be used.

Sounds reasonable to me!

> I can probably try to make a revised version of the packet 
> formats later this week if this is the way we decide to go.

That would be appreciated!

> Let the flaming begin.

I'll leave that to others!

/L-E