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

From: "Wang Hui" <[email-masked]>
Date: Tue, 3 Dec 2002 21:34:55 +0800

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 9 Dec 2002 09:52:22 +0100

Wang,

> 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'?  

Some observations:
- E.g. profile 1 is not made in a modular way, i.e. we have 
  not separated the three headers, but compressed them in a
  combined way (for increased compression efficiency).
  Compressing only IP/UDP or just IP do require more than
  just saying "we compress only IP", as we have seen when
  discussing the IP profile.
- We already have a profile for IP/UDP and another for 
  IP/UDP/RTP. An additional profile for IP only is also on
  its way. The profile ID is used to choose which one to use,
  and that works.
- The profile ID space is rather large, 256 "base profiles",
  i.e. profiles with different LSB's, and for each such we
  can have 256 "non parallel" profiles (e.g. upgraded ones).
  This is a huge number of profiles, considering that we do
  not expect having to standardize that many new profiles.
- Having a way to use only a subset of a profile could of
  course be provided in a new profile by in-band signaling
  (defined for that specific profile), but that would add
  bits for something that could as well be handled by
  different profile ID's. 
- The profile negotiation is already defined and in place. 
  We can add new profiles and change the way we define new
  profiles, that is a flexibility built into the ROHC
  concept, but changing the negotiation principles would be
  very bad for ROHC.

Did you have any comments on the IPv6 extension and list
compression discussion below?
 
> > 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 list
> > 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).

BR
/L-E

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 10 Dec 2002 10:46:35 +0100

> Hello,
>   I read draft-hwang, it suggests processing MIPv6 HOA
> and Type 2 routing headers with a ROHC profile. 
> The draft seems to have found some encouragement
> from the statements in RFC 3095 which says that when
> MIPv6 is finalized maybe a special profile will be
> needed for MIPv6.
>   From the discussions on the list, Lars-Erik is
> asserting that RFC 3095 is sufficient in order to
> process these two types of IPv6 extension headers, to
> which I have nothing to say. These two headers have
> existed in MIPv6 since 1996 so I do not see any reason
> why RFC 3095 could not compress them

This is a good observation, and I agree that the text
in 3095 might have caused confusion. However, it just 
said that "...future work MIGHT be required...".

>   Maybe what we need is to modify the statements on
> MIPv6 in RFC 3095, that's all.

Since RFC's can never be changed, we can not do this.
However, now the issue has at least been discussed on
the list so people who were not among us in 2000 now
know about this. We have also identified a need to 
have more discussions about list compression, which is
something I would encourage people to initiate on the
list. When we take 3095 further to draft standard, we
will of course make sure the misleading text about
MIPv6 is removed.

Cheers,
/L-E