Subject: RE: [rohc] Do we need a special profile for Mobile IPv6 packets?

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 6 Dec 2002 11:57:54 +0100

Wang,

Your draft addresses an important issue, which we should indeed make
sure that we cover for when we define future profiles. However, the way it
is currently written might not match the ROHC profile concept. We can not
define a separate profile for e.g. MobileIPv6, and use that in combination
with other profiles. If additional functionality is needed, we will have
to define new profile(s) extending the original profile(s). It would then
be e.g. an enhanced IP/UDP/RTP profile with additional capabilities.

Further, the draft does not explain what is missing for MobileIPv6 support
in profile 1,2, and 3. RFC 3095 defines a list compression scheme for
RTP CSRC lists and IP extensions. The following items can be part of a
compressed list (see section 5.8, page 104):
  - AH header
  - null ESP header
  - minimal encapsulation header
  - GRE header
  - IPv6 extension headers

According to your draft, the extension headers that would have to be
handled for MIPv6 can basically be considered as static. I am therefore
not sure what explicit compression mechanisms would be needed to compress
these, since the list compression scheme should already be capable of
compressing these headers, i.e. to initialize them as list items, which
can thereafter be omitted as long as they do not change (and if they do,
that can also be handled).

I might be wrong, or I might have missed something. In such case, please
correct me. RFC 3095 states in the abstract that "future work might be
required to handle some extension headers", but my impression is that
this should at least not be needed for the cases addressed by your draft.

Cheers,
/L-E

> -----Original Message-----
> From: Wang Hui [mailto:[email-masked]]
> Sent: den 3 december 2002 14:35
> To: [email-masked]
> Subject: [rohc] Do we need a special profile for Mobile IPv6 packets?
> 
> 
> Hi folks here,
> 
> In my implementation experience of ROHC to the wireless 
> application deployment, I found Mobile IPv6 will play an 
> important role.   So I think we may develop a special profile 
> to deal with Mobile IPv6 packet.  I write a draft for this 
> purpose.  But for some reason, there are some bugs in the 
> current draft I posted.  :((  I think I will revise it if it 
> is worthy of that.  And I want to hear your advice.  Any idea?
> 
> The draft was just put to the on-line Internet-Drafts 
> directories.  A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hwang-rohc-mipv6-00.txt
> 
> 
> Best,
> Wang
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Francis Dupont <[email-masked]>
Date: Sat, 07 Dec 2002 16:52:22 +0100

In your previous mail you wrote:

   According to your draft, the extension headers that would have to be
   handled for MIPv6 can basically be considered as static.

=> the extensions headers are the most static part in a Mobile IPv6
communication. For instance, the home address option is same in all
packets when the source address in the IPv6 header changes at each
handoff... So I fully agree with Wang.

   I am therefore
   
=> IPv6 option extensions are not like the TCP options: even the list
compression can handle them this can become highly suboptimal.

=> in theory no compression at all is needed (:-)...

Regards

[email-masked]

PS: in my real world IPv6 experience, I never found a dynamic option.
You can transmit the question to the IPv6 WG if you don't believe me
but if the ROHC WG has still some interests in a reasonable support
of IPv6, ideas like presented in draft-hwang-rohc-mipv6-00.txt
should be taken into account.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Wang Hui" <[email-masked]>
Date: Mon, 9 Dec 2002 10:27:24 +0800

Hi,  Jonsson,

See my comments inline.

> be e.g. an enhanced IP/UDP/RTP profile with additional capabilities.
Yes, my idea is just as you described above.   

Now,  I happen to have another idea.  Shall we add a 'flag' as a additional field to 
the current profile id?  The 'flag''s bits indicate the compression coverage.  
For example,  if we have a 16-bit flag, the first bit is to suggested to indicate  
whether we have IP base header compressed, and the second bit is suggested to indicate 
whether we have the UDP header compressed,  and then the third bit is about the RTP header. 
If the bit is set to '1', the corresponding field is indicated to be compressed.   
So we can choose to compress only the RTP header and UDP header, not the IP header. 
And in this case,  the 'flag' is set to '0x0006' ( the low 4-bit is '0110').  

I don't know if the 'flag' is a good idea.  But currently, I think this 'flag' is more 
scalable then the currenly used 'profile id'.  This idea of setting 'flag' field will 
give people the free to choose what they want to compress according to their own thoughts.

Any idea on this 'flag'?