Subject: RE: [Fwd: Re: [rohc] IPv6 deployment in profile 2 and 4]

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 2 Aug 2002 13:10:37 +0200

Ana,

> We are interesting in the compression of IPv6 header, and analising you
> draft we found some problems using it with IPv6.
>
> Perhaps your proposition is correct for IPv4 but it needs something more
> simple for IPv6. As IP-Id is not in the original header, new format
> packets for IPv6 can be proposed?

I would not say that something else is *needed* for IPv6, but I would
agree that one could argue for having different formats. However, the
approach taken in this document is the same as for the IP/UDP profile,
i.e. to have the same formats for both IPv4 and IPv6. The whole idea
with this profile is to be totally based on the IP/UDP profile, with 
the simplest possible modifications. 

> Another porblem we found, but perhaps you have the solution is: in
> the transition modes is that the IR, IR-Dyn and UOR-2 do not contains
> the mode in which the compressor is working, only when you send UOR-2
> with extension 3 then the transition is finish, in our implementation,
> the transition is blocked until an UOR-2+ext3 arrives!  In profile 1,
> the mode is added in  the original RTP header, then it is send in IR,
> IR-DYN, UOR-2 packets, then as in profile 4 there is not RTP then the
> mode is not added.

I do not really understand what the problem is here. The proposed IP
profile has the same formats as the IP/UDP profile, with mode bits in
extension 3, exactly as for the IP/UDP/RTP profile.

Further, I do not know what you mean with "transition is blocked". Which
transition do you refer to, and at which stage? Please refer to the
transition diagrams, either of RFC3095 or the simplified (but compatible)
alternatives in the implementer's guide. I guess you talk about the
first compressor response to a mode transition initiation, and there 
you would have to accept IR, IR-DYN or UOR-2 with mode bits, and the
compressor is responsible for sending such packets until at least one
of these have been acknowledged (of course not for U->O transition).

Cheers,
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

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

---

From: Ana Carolina Minaburo <[email-masked]>
Date: Thu, 08 Aug 2002 11:16:28 +0200

Hi!

Sorry for not answering before

>the simplest possible modifications. 
I do not understand what you mean with simplest modifications? Are you 
refering that  it is not possible to have a separate IPv6 format?

>extension 3, exactly as for the IP/UDP/RTP profile.
Well, in IP/UDP/RTP profile, we are not only sending mode in extension 
3, the RFC section 5.7.7.6 give the dynamic part of RTP protocol in 
which you are adding 2bits to send the mode. If this is like that, then 
this dynamic part could be sent also in IR-DYN and if IR packets used 
dynamic part. Then the decompressor can know in which mode compressor is 
working and he does not need to wait until an extension 3 arrives.

In the description of IP/UDP profile, the mode is only sent in extension 
3, but extension 3 is sent only when an updating is taking place an not 
normally.

>of these have been acknowledged (of course not for U->O transition).
Yes, I am refering to the first response of compressor. We run the 
compression and when a transition different from U->O is taking place, 
as for example from O->R, but this is happenning also in the other 
transitions sauf U->O that is direct. I mean transition is blocked 
because decompressor is waiting for a packet with mode bits, but this is 
only happening when and UOR-2+extension 3 is sent, because IR and IR-DYN 
packets do not have mode bits.
We are thinking that perhaps for IP profile, sending UOR-2+ext3 packets 
as the only possible response of compressor could be a solution to 
reduce the time ROHC pass in the transition.

Regards!
Ana