Re: ROHCv2 Packet Formats
Carl Knutsson <[email protected]> Wed, 11 Nov 2009 17:07:05 +0100
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <[email protected]> |
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: > 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