Subject: [mobile-ip] RE: Comments on hmipv6 draft and a proposal on a third mode

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Mar 2001 00:14:07 +0200

James, 

One other thing I forgot to mention is that whether 
you tunnel or not, the header will change every time 
the MN moves. Unless we assume a MIPv4 model.

Hesham

> -----Original Message-----
> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Wednesday, 28 March 2001 2:34
> To:	[email-masked]; [email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject:	RE: Comments on hmipv6 draft and a proposal on a third mode
> 
> Hesham,
> 
> >
> >> I understand that
> >> this would be useful for IPRAN  as James Kempf had pointed out 
> >> earlier in the list.
> >> 
> >	=> Not really, all IP based cellular systems will use ROHC
> >	or something equivalent. To be more specific 3GPP will
> >	and I believe 3GPP2 is making (or has made a similar 
> >	decision). 
> >
> 
> Neither 3GPP nor 3GPP2 currently has all IP RANs. 3GPP2 is discussing
> whether to start work on a new all IP RAN architecture. 3GPP, having
> just completed the UTRAN architecture, has so far declined to
> investigate all IP RAN, being content with introducing IP as an
> alternate transport layer protocol.
> 
> That said, I agree that header compression will likely play a role
> even in an all IP RAN. That does not negate the advantage of removing
> tunnelling overhead. In particular, if the tunnel changes during
> handoff, it could cause the compressor to revert back to the start
> state, resulting in some number (the number is currently disputed)
> of packets required to restart the compressor. I've seen numbers from
> 60-600 ms quoted as required on a radio link with a 20 ms frame transmit
> time, I am trying to reduce the uncertainty by corresponding with the ROHC 
> working group chairs. Any amount of additional delay caused by having
> to restart the compression state machine at the beginning would thoroughly
> negate the low latency handoff work.
> 
> Note that, unlike IPv4, the headers *will* change even if there is no
> tunnel overhead in IPv6 because the CoA will change when the mobile
> moves to the new access point, and the CoA gets sent out over the 
> air. In IPv4, the FA strips the tunnel overhead, so the compressor
> state remains the same and could potentially be shipped across the
> wire in a context transfer protocol (Seamoby). In IPv6, it is as yet
> uncertain if the compressor state could be maintained during handoff.
> And it may turn out that changing the CoA would allow the compressor
> state to be transferred, but changing the tunnel would not.
> 
> The ROHC group seems to have been exclusively focused on IPv4. From
> my conversations with the working group chairs at IETF in Minneapolis,
> they seemed unaware that the header would change during handover
> in IPv6.
> 
> My conclusion from this is that it is dangerous to make blanket assumptions that
> header compression will solve problems with fat IPv6 headers lacking
> solid data about whether the compression algorithms can use context
> transfer to reestablish state and also reinitialize the state machines
> with the new CoA. I hope this will become somewhat clearer as we get
> more data from the ROHC working group.
> 
> If you are interested in helping to find this out, I suggest you generate
> a couple of HMIPv6 headers including the tunnelling overhead both
> before and after handover and send them to the ROHC chairs. They requested
> I do this for straight IPv6 headers. They will then be able to tell
> you whether or not the compressor can be restared without moving back
> to the start state. Then you can base your HMIPv6 design on solid data,
> rather than assumptions.
> 
> 			jak

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 28 Mar 2001 09:58:23 +0200

> the MN moves. Unless we assume a MIPv4 model.

Hello,

I think what James is saying is that header compression
will be difficult for MIPv6...i.e. no packets will be compressed
... it is better not using tunnels...
Am I right James?

I am not completly convinced about this arguments and I am sure that
the RoHc will eventually find a solution...

However if we assume that this problem will not be solved, I think that I would
make more sense to have the wireless access routers decapsulate the packets coming
from the MAP and forward them on the air link... these packets could then be compressed
because the destination address does not change (the destination is the RCoA) as long as the MN
is supported by the same MAP (i.e. the RCoA does not change).

This requires to modify the wireless access routers but you gain even more than the proposed 3rd mode
in term of bandwidth comsumption because header compression is then possible on the air link....

Comments?

thanks,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/