Subject: [rohc] ROHCv2 Packet Formats

From: Anil Maguluri <[email-masked]>
Date: Tue, 10 Nov 2009 17:08:50 +0530

Hi All,

Please can anyone explain me how to compress IPv6 extension headers in 
ROHCv2?

Please clarify me whether my understanding is right or not. Also clarify 
me the below queries.

My understanding as per RFC 5225,
1. we have to consider the IPv6 extension header as a normal header and 
use irregular chain
to build in the compressed packet (Refer 6.6.1. 
baseheader_extension_headers)

2. should consider while selecting the CID. If the adding or removing of 
the extension header 
considered as a new flow and proceed.
" RFC 5225: 4.2  Improvements of ROHCv2 over RFC 3095 Profiles
IP extension header

      Profiles in RFC 3095 compress IP Extension headers using list
      compression.  ROHCv2 profiles instead treat extension headers in
      the same manner as other protocol headers, i.e., using the
      chaining mechanism; it thus assumes that extension headers are not
      added or removed during the lifetime of a context (CID), otherwise
      compression has to be restarted for this flow.
"

Queries
1. In case of sending IPv6 extension header in IRREGULAR chain, which 
format do
we need to use to build?
2. In case of change in the data field in extension header, do we need to 
send complete
extension header? if yes, on which format?

Thanks for your support.

Regards,
Anil Kumar Maguluri

______________________________________________________________________

---

From: Klaus Warnke <[email-masked]>
Date: Tue, 10 Nov 2009 15:13:29 +0100

Hi Anil,

comments inline...

At Tue, 10 Nov 2009 17:08:50 +0530,
Anil Maguluri wrote:
> 
> Hi All,
> 
> Please can anyone explain me how to compress IPv6 extension headers
> in ROHCv2?
> 
> Please clarify me whether my understanding is right or not. Also
> clarify me the below queries.
> 
> 1. we have to consider the IPv6 extension header as a normal header
>    and use irregular chain to build in the compressed packet (Refer
>    6.6.1.  baseheader_extension_headers)
> 
> 2. should consider while selecting the CID. If the adding or
>    removing of the extension header considered as a new flow and
>    proceed.
>
>       compression.  ROHCv2 profiles instead treat extension headers
>       in the same manner as other protocol headers, i.e., using the
>       chaining mechanism; it thus assumes that extension headers are
>       not added or removed during the lifetime of a context (CID),
>       otherwise compression has to be restarted for this flow.  "
> 
> Queries
>
> 1. In case of sending IPv6 extension header in IRREGULAR chain,
>    which format do we need to use to build?

With the ah_irregular and gre_irregular formats. Or did I
missunderstood something?  In the irregular format are data sent,
which can not be compressed otherwise. For gre, for example, it is
"optional_checksum", if present, and the (optional) sequence_number,
if present.

> 2. In case of change in the data field in extension header, do we
>    need to send complete extension header? if yes, on which format?

Yes, with an IR packet, because a new flow was detected.

If a field, which is STATIC/STATIC-DEF declared, contains data that
does not match of any defined contexts/flows, a new flow starts. That
is, you can not transmit changes of data in extension headers, because
a flow with different data in extension headers defines a different
flow. Excepted the as IRREGULAR/PATTERN defined fields in AH and GRE
extension headers. See A.8. for GRE and A.10. for AH. These field data
are sent in the irregualr chain.

> Anil Kumar Maguluri

br
Klaus

---

From: Anil Maguluri <[email-masked]>
Date: Wed, 11 Nov 2009 10:22:40 +0530

Hi Klaus,

Thanks for your response.
Please clarify my queries (inline in the below mail). 

Regards,
Anil Kumar Maguluri

Klaus Warnke <[email-masked]> 
11/10/2009 07:43 PM

To
Anil Maguluri <[email-masked]>
cc
<[email-masked]>
Subject
Re: [rohc] ROHCv2 Packet Formats

Hi Anil,

comments inline...

[ANIL]
How to send IPv6 Extension Headers (Destination Option, Routing
header, Hop-by-Hop options) in ROHCv2? 
The above extension headers are classified in static and dynamic fields.
There is no irregular fields in those headers.
1. Do we need to consider static fields while selecting the flow? 
For example: In case of Destination option, next_header and length are 
static fields. If the length value changes means is that is new flow?
2. How to send (in which packet) if the dynamic field value changes?
For example: In case of Destination option, value is dynamic. If the 
value changes, on which packet do we need to send value information?

br
Klaus

---

From: Klaus Warnke <[email-masked]>
Date: Wed, 11 Nov 2009 11:18:38 +0100

Hi Anil,

At Wed, 11 Nov 2009 10:22:40 +0530,
Anil Maguluri wrote:

> The above extension headers are classified in static and dynamic
> fields.  There is no irregular fields in those headers.

Yes.  Btw, RTP has also no irregular fields, that is, the
rtp_irregular format is empty.

> For example: In case of Destination option, next_header and length
> are static fields. If the length value changes means is that is new
> flow?

Yes.  The only specified way to transmit the next_header and length
field is the dest_opt_static format. And, see 5225 6.5: "The static
chain is only used in the IR header format.".  Therefore the only way
is the IR packet. And the IR initializes the whole context. But you
can (should?) use the same CID, if you are sure, that is the same
flow. From decompressor point of view it makes no difference. I think,
this szenario occurs seldom, so there is no smaller packet defined to
transmit such changes. In RoHCv1 the extension headers were compressed
with the so called table based compression. I implemented that, and I
can say it was very, very difficult for me. On one hand, as in RoHCv1,
you can define a difficult to implement feature to save some octets
for a seldom ocurring szenario with a high risk, that the
implementations are not interoperable, or, as in RoHCv2, an easier to
understand and implement mechanism, which wastes some octets. That is
my point of view.

> value changes, on which packet do we need to send value information?

The dynamic chain is used in the IR and co_repair packets: "The
dynamic chain is only used in the IR and co_repair header formats.".
Therefore you can use both of them. The co_repair format is intended,
if a context damaged is assumed, but I think you can use it also for
that szenario. I think, I prefer using the IR header.

I hope, that helps.

br
Klaus

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 11 Nov 2009 17:07:05 +0100

Hi Anil, Klaus,

Just to avoid any misunderstanding, I want to add one comment to Klaus
answer. The IR packet doesn't reinitialize the whole context. So you
cannot automatically reset the decompressor context at the reception of
an IR packet (see RFC 4995 section 5.1.3. and section 5.2.2).

cheers,

/Calle

Klaus Warnke wrote:
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc

---

From: Klaus Warnke <[email-masked]>
Date: Wed, 11 Nov 2009 17:31:28 +0100

At Wed, 11 Nov 2009 17:07:05 +0100,
Carl Knutsson wrote:
> 
> Hi Anil, Klaus,
> 
> Just to avoid any misunderstanding, I want to add one comment to
> Klaus answer. The IR packet doesn't reinitialize the whole
> context. So you cannot automatically reset the decompressor context
> at the reception of an IR packet (see RFC 4995 section 5.1.3. and
> section 5.2.2).

Which value(s) are not updated with the IR packet(rfc 5225 6.8.1.)?
Could you please give an example?

thx
Klaus

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 12 Nov 2009 12:01:20 +0100

> Could you please give an example?
The CSRC translation table for example.

cheers,

/Calle

---

From: Klaus Warnke <[email-masked]>
Date: Thu, 12 Nov 2009 12:36:27 +0100

At Thu, 12 Nov 2009 12:01:20 +0100,
Carl Knutsson wrote:
> >> context. So you cannot automatically reset the decompressor
> >> context at the reception of an IR packet (see RFC 4995 section
> >> 5.1.3. and section 5.2.2).
> > 
> > Which value(s) are not updated with the IR packet(rfc 5225
> > 6.8.1.)?  Could you please give an example?
> > 

And what is about the csrc_list in the rtp_dynamic format?

If there are csrc values (cc.UVALUE parameter for csrc_list_dynchain
encoding method > 0), a csrc_list must sent. Or did I unterstood
something wrong?

br
Klaus

---

From: Carl Knutsson <[email-masked]>
Date: Mon, 16 Nov 2009 13:00:23 +0100

> encoding method > 0), a csrc_list must sent. Or did I unterstood

The CSRC list must always be sent in the dynamic chain, but there is a
difference between the CSRC list and the CSRC translation table
(index-item mapping).

cheers,

/Calle