Subject: RE: [mobile-ip] RE: [rohc] RE: Restarting Compressor on Mobile IP v6 Handover

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 1 Apr 2001 19:19:53 +0200

> > > I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
> > > provide header compression support, which involves context initialization,
> > > which in turn could be avoided during handovers using context relocation!
> > > 
> > 	=> No, I disagree. IP_deployment_in cellular networks relies 
> > 	on ROHC. MIPv4/v6 in general relies on ROHC to be deployed
> > 	in cellular networks. This is the reality. If you're sending complete
> > 	IP headers in a VOIP call, then I'll just stick to my GSM phone.
> 
> 
> But the fact is that HMIPv6 draft is making an assumption that ROHC  is a 
> pre-requisite to implement HMIPV6 support. 
> 
	=> Where does the draft make this assumption ?
	Is it because packets are tunnelled ? 
	If so then MIPv4 and MIPv6 are making that assumption.

> So, from your above statement, it is clear that hmipv6 is only targeting
> cellular systems that will have ROHC or rfc2507 HC implemented.
> 
	=> I don't understand how that conclusion is drawn. Fixed
	lines also use header comprssion. ANY narrow-band link 
	will use it. In other words, wherever BW is scarce some
	form of header compression is needed.

> BTW, HMIPV6 draft talks about hierarchical networks in general, why do you
> assume that ROHC will be implemented in all hierarchical networks. 
> 
	=> I'm not assuming it, I'm assuming some form of HC will 
	be done if network administrators want to save BW. Not
	just for (H)MIPv6 but for IP in general. 

> There
> may be small  scale wireless networks which may not have header compression
> at the access points.
> 
	=> Sure.

> Also, in regular netwroks, if I have a choice of saving
> 40 bytes, why don't I do that ?
> 
	=> Sure you can. But you'll only do so if you use 
	your proposal and make sure MNs don't use 
	a HA, ie. MUST use HMIPv6 and route optimisation. 
	Also you'd have to make sure that no other prtocols
	(that use tunnelling) are allowed. 

	That's might be possible, I didn't say it's not possible. All I said
	was that we're trying to scope this draft and 
	get it done and I suggested that you have it in another
	draft. What's wrong with that ?
	In fact that's what the RR authors did and their 
	Reg-fwd draft is separated from the main draft 
	and includes the same idea you proposed. So I don't 
	see why it couldn't be done for HMIPv6. 

>   The third mode proposal is not complex at all
> and it does only destination address substitution once at MAP and once at MN, 
> mobileIpv6 is doing similar mechanism at end nodes  with homeaddress option.
> So may be 10-15 lines of additional code.
> 
	=> That's fine, I never said it can't be done, what 
	I suggested was to put it in another draft. 
	I don't think there is anything wrong with that. 
	The entire HMIPv6 (basic mode) was implemented
	in 300 lines, but we didn't suggest putting it 
	the MIPv6 draft. 

	Hesham