Subject: Re: [mobile-ip] MIP v6 Regional Registration - identifying re quirements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 9 Apr 2001 17:11:05 +0200

> 	(The authors of HMIPv6 prepared some answers and Claude
> 	was meant to send it but I guess it was lost. Sorry if you 
> 	get multiple copies).
> 
> 	Hello Phil, 
> 
> 	This is a great start. Thanks for taking the time. 
> 	We're not sure why it is referred to as RR but anyhow 
> 	that's just a name and we all know what you mean
> 	(Localised moility management). 
> 
> 	We will only answer to the validity of the requirements and 
> 	not to where HMIPv6 stands in terms of supporting a 
> 	requirement. We think it is better to first agree on a set 
> 	of requirements and take it from there.
> 
> 	I think I've finally caught up on all the mail about regional registrations
> 	for MIP v6 and HMIP.  There seems to be significant concerns about the task
> 	to be accomplished and the specific approach that is specified in the HMIP
> 	draft.  A short list of concerns include worries about introducing single
> 	points of failure, whether or not multiple levels of hierarchy are needed,
> 	the amount of signaling and tunneling overhead that is implied, the
> 
> 	=> We believe we got some confirmation for ROHC and CT
> 	folks that tunnelling will not be an issue. 
> 
> 	relevance of load balancing and the particular metrics in the HMIP draft,
> 
> 	=> Based on the comments received in Minneapolis we thought 
> 	it would be good to have load balancing (for HA/MAP/CN) in a separate draft.
> 	Unless  there is consensus against this, we will do that.
> 
> 	Here's a short list of requirements drawn from comments received over the
> 	last month or so and from the HMIP draft that the working group participants
> 	can use as a basis for discussion.  Please understand that this is not the
> 	list of requirements I believe are needed 
> 
> 	=> Understood.
> 
> 	=> Here are some comments. Hopefully these comments 
> 	should cause the people who raised the requirements 
> 	to provide some reasons for raising them.
> 
> 	=> BTW, the single point of failure issue is not an HMIP
> 	specific problem. However HMIPv6 has less single 
> 	points of failure than other proopsals. 
> 
> 	We would like to add two more requirements. 
> 
> 	0) Localised mobility management should provide the same
> 	level of mobility management support as in the basic 
> 	MIPv6 specifiation. The mobility management functions 
> 	supported in MIPv6 must not be reduced in such mechanism.
> 
> 	0.5) The provided mechanism must interwork with existing 
> 	MIPv6, IPv6 and the proposed mechanisms for SA establishment
> 	in MIPv6. 
> 
> 	1) Regional registration shall be introduced to minimize the signaling
> 	traffic to the home agent or correspondent nodes for intra-domain mobility
> 
> 	=> Agreed
> 
> 	2) Regional registration shall not introduce new overhead on links between
> 	the mobile and the regional registration agents
> 
> 	=> We're not sure what this means. However if it means no more
> 	overhead than a BU then it's seems like a reasonable requirement.
> 
> 	3) Connectivity to the mobiles shall not be interrupted in the presence of
> 	the failure of regional registration agents
> 
> 	=> Agreed. Although this should trigger some redundancy work
> 	in the MIP WG. But it should be kept as a target.
> 
> 	4) Regional registration shall scale to support millions of nodes in a
> 	visited network
> 
> 	=> Agreed.
> 
> 	5) Regional registration shall be secure against malicious behavior from
> 	visiting mobiles
> 
> 	=> Agreed.
> 
> 	6) Regional registration shall allow multiple levels of hierarchy
> 
> 	=> We can't see a reason for this requirement. We think it's 
> 	 OK if we want to support mobile networks but we don't 
> 	think this requirement should be placed for all cases. 
> 	We never got an answer for the technical merits of 
> 	this requirement. It would be good to know why. Otherwise 
> 	we'd like to remove this requirement.
> 
> 	7) Regional registration shall support fast handoffs> 
> 
> 	=> If that means coexist with the current FH proposal
> 	then we agree.
> 
> 	8) Regional registration shall not require changes to the mobile node, the
> 	home agent, or correspondent nodes
> 
> 	=> We can understand the HA and CN, but no changes in the MN
> 	seems strange. Is this possible ? 
> 
> 	9) Regional registration shall not introduce host routes in routing tables
> 
> 	=> Agreed. As long as a Binding Cache entry is not regarded as 
> 	a host route ? strictly speaking.
> 
> 
> 	Hesham, Claude and Karim
>

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 09 Apr 2001 09:01:35 -0700

Hi all,

  I agree that localised mobility management is probably a neutral term here and better
for the discussions.

I have some questions WRT  Phil's requirements list..

> >       supported in MIPv6 must not be reduced in such mechanism.

Could we have an example that constitutes a reason for such a requirement? I was under
the impression that this was not an issue. Basically I am not clear on the possibility
for reduction of the mobility management mechanisms in core MIPv6.

> >       MIPv6, IPv6 and the proposed mechanisms for SA establishment

I thought that the localised mobility extensions are working by default over core MIPv6
otherwise they would not be extensions. As such I assume a default fallback to core
MIPv6 is the extensions do not come in effect. Aren't we stating the obvious here?

> >       overhead than a BU then it's seems like a reasonable requirement.

I agree this is not clear. Are we talking about extraneous signalling compared to core
MIPv6? I think this is unrealistic since each approach may tackle localisation from a
different angle/perspective and thus may have different signalling requirements. I
would not expect a single BU to be the only signal since both localised mobility
schemes introduce configuration of mobility agents with RT advert options. I think this
is part of the protocol even if people push it as a configuration issue, since without
it the protocol does not work!

> >       in the MIP WG. But it should be kept as a target.

I think that a single point of failure cannot be avoided by any localised
scheme/extension to core MIPv6. The reason is simple: each scheme todate has got a at
least one mobility agent that provides the localisation effect for the MN to the rest
of the world. If that mobility agent goes down, then this will be the end of it and
this goes for ANY localised mobility scheme unless people want to convince me for the
opposite. As such while one requirement must be that the main mobility agent of
reference (GMA, MAP) must not be allowed to degrade the benefit of the extension by
failing, it is unavoidable for any scheme and thus a primary requirement.

If the multiplicity of points of failure increase beyond 1, we need to attempt a
minimization of them while sustaining the benefit of the extension in mobility, but
also consider the actual tradeof for introducing it. That is optimizing localisation.

> >       we'd like to remove this requirement.

The fundamental reason for which I am convinced that multiple level of hierarchy do
make a difference is the optimization of the localisation point. I won't elaborate
further on the distribution of the signalling within a multi-level hierarchy per MN,
but this is also another positive point.

I feel that the requirement should stay but not be mandated.

> >       seems strange. Is this possible ?

the localised extensions for the MIPv6 protocol are extensions because they provide
somewhat special treatment in the localisation effect. In this the MN is the PRIMARY
participant. Asking the MN to behave with nothing more than core MIPv6 functions is
effectively excluding the MN from the special treatment that can make the extensions a
reality. I believe that the requirement for no changes to the MN should be removed.

> >       a host route ? strictly speaking.

I think here we have renamed things at one level (B-Cache) and masked out temporaly the
issue of host routes. I think this is incorrect since host routes ARE already in the
B-Cache and as such if such requirement is in effect and we want to be correct we have
to scrap the B-Cache, which is an absolute no-no.

Under this light I feel that the requirement for no introduction of host routes is not
realistic. However, minimizing the amount of host routes should be a requirement.

> >       Hesham, Claude and Karim

Theo

UCL/ Mobile Systems

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 09 Apr 2001 09:01:35 -0700

Hi all,

Theo

UCL/ Mobile Systems