Re: ROHCv2 Packet Formats

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

> cheers,
> 
> /Calle
> 
> Klaus Warnke wrote:
> > Hi Anil,
> > 
> > At Wed, 11 Nov 2009 10:22:40 +0530,
> > Anil Maguluri wrote:
> > 
> >> 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.
> > 
> > Yes.  Btw, RTP has also no irregular fields, that is, the
> > rtp_irregular format is empty.
> > 
> >> 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?
> > 
> > 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.
> > 
> >> 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?
> > 
> > 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
> > _______________________________________________
> > Rohc mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rohc
>