Subject: [mobile-ip] Simplified Hierarchical MIPv6 (was...)

From: James Kempf <[email-masked]>
Date: Thu, 15 Mar 2001 15:19:11 -0800 (PST)

Hesham,

I don't want to get into a long discussion over this, since I've
got a lot of other stuff to do before I leave for the Mini-Apple
on Sun., but the fact remains that both hierarchical proposals introduce
extra signalling and also some extra tunneling overhead over the air.
Air resources are scarce if the network operator needs to pay for them,
and so reducing air time is a significant plus.

I think that Glenn's proposal deserves a serious look. It may turn
out to be technically infeasible in the end but as has been pointed out,
IPv6 is significantly more malleable at this point than IPv4 so there's
no reason not to look for a simpler solution. If it
turns out not to work, then we can return to one of the existing
proposals. And there may be other reasons (like providing a local home address 
for homeless clients, as the MAP can) to use one of the existing
solutions.

I suppose a good set of requirements would have helped to avoid these
problems.

		jak 

>X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
[email-masked] using -f
>From: "Hesham Soliman  (ERA)" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] FW: I-D ACTION:draft-malinen-mobileip-regreg6-01. txt
>Date: Thu, 15 Mar 2001 20:48:40 +0100
>MIME-Version: 1.0
>List-Archive: <http://playground.sun.com/mobile-ip/>
>List-Owner: <mailto:[email-masked]>
>List-Subscribe: <mailto:[email-masked]?body=subscribe>
>List-Unsubscribe: 
<mailto:[email-masked]?body=unsubscribe> Sorry to jump in 
as you were addressing Glenn,  but I have to correct some misunderstandings 
about HMIPv6.
>
>> > Hello,
>> > 
>> > I still do not understand why the ability to place something at an 
arbitrary point justifies destroying the connectionless nature of a IP or even 
IP mobility.
>> 
>> Once we introduce an intermediary point (HA/RMA/MAP) with mobility bindings
>> we introduce state used in a similar way as state used for maintaining
>> plain next hop forwarding. 
>> 
>	=> The  next hop forwarding in the MAP depends on the routing 
>	protocols in the domain. The next hop forwarding in Regional
>	is forced (like a static route). There is a big difference. 
>	You might ague that reg6 is part of MIP, hence can be 
>	classified as a routing protocol, but I would say that 
>	any routing protocol that reserves a "circuit-like" path
>	in the IP network is not acceptable.
>
>> I read your use of term connection-oriented to
>> mean the use of mobility bindings for forwarding instead of exclusively 
relying on host/network/default routes. Introducing robustness
>> in this form of forwarding is a problem both HMIP and regreg6 face.
>> In fact, even basic Mobile IPv6 while forwarding packets via the
>> home agent has this feature.
>> 
>	=> The robustness in terms of introducing a single point 
>	of failure may be similar, but adding a less robust path
>	to the MN from the GMA is not acceptable, and clearly 
>	this is not just my opinion.
>
>	Regards,
>	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Mar 2001 01:56:39 +0100

> We would like to see elimination of *all* tunnelling overhead over
> the air (and that includes HA overhead folks) if possible. For example,
> by stripping it on at the last hop router, where it is no longer 
> needed.
> 
> Barring that, we would like to see an analysis that indicates header
> compression will work to eliminate tunnelling overhead, and that
> it can be moved quickly enough during handover that it will not
> negate the gains of the low latency handover protocol. 
> 
	=> I am not an expert on header compression by any means
	but based on my several discussions with some experts in
	the area, I was told that ROHC will handle tunnelling 
	and Extension headers at no extra cost over the air.

	So if this true,I wonder if tunnelling is a problem.

> I do not
> get the feeling from the Seamoby context transfer problem statement
> draft that this is possible.
> 
	=> I haven't looked into it in detail, have you
	heard of some reasons ?
	Perhaps this context transfer discussion needs to be 
	taken to the seamoby list, but I'm wondering what 
	the negative impacts are if we do not transfer the 
	context for header compression. In the worste 
	case scenario I am told that maybe 2 or 3 packets
	will be sent with a full header. But that doesn't 
	mean loss of service, just a short period of inefficiency
	over the air. Is that true ? Does anynoe know more about 
	this ?

	Thanks,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Mar 2001 04:45:19 +0100

> >         => Sure air resources are scarce and expensive, especially
> >         in many cellular systems where they cost billions.
> >         BUT, even one IPv6 header is too expensive, especially for real
> >         time services. So what does every IP based cellular system
> >         do, they use Header compression. It can handle tunnelling.
> 
> There are some reasons why we can do better by considering last hop
> resource usage on the network layer than delegating it to the header
> compression, which is a link-layer optimization. To my knowledge,
> header compression is application specific. You need to set up the
> context to use it and that depends on what application you are
> running. Setting it up for voice is different from e.g. for video.
> What if you have application for which you do not have a method?
> 
	=> Like what ? As far as I know neither the application nor the 
	IP stack needs to be aware of Header compression. Perhaps
	what you're referring to is the setup of special radio bearers
	for special applications. But I don't see the relevance to 
	header compression. Can you give an example ?

> If you can strip tunneling by a simple application-independent
> IP forwarding trick, then why not? Also, why should we mandate
> support for header compression to have efficient bandwidth usage?
> 
	=> We're not mandating anything, it's already in every 
	low/scarce BW link. This is not something we're adding. 

> I do not think we should ignore WLAN-like interfaces, either, where
> header-compression is not included.
> 
	=> Nothing stops it from being included. Header compression
	was included by designers of sytems/links that saw the need 
	for it, like dialup lines and cellular networks. There is 
	nothing in the spec (to my knowledge) that stops other
	systems from using it.

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 26 Mar 2001 01:30:46 +0200

>  > negate the gains of the low latency handover protocol. I do not
> In particular, I think that the case of mobile
> routers needs to be considered closely. The
> likelihood of the need for many compression
> contexts (which I don't _think_ is possible in
> CRTP/ROHC, but could be wrong) may be problematic.
> 
	=> In the MR case there is no need to tunnel
	over the last hop. We've considered it carefully
	already, but we'd still like to know if you see any
	problems in it. 

	Hesham