Subject: RE: [mobile-ip] Some questions on Hierarchical MIPv6

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 20 Mar 2001 00:10:28 +0100

> > >
> > > In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP.
> > > The question is which one the home address or the onlink (LCoA)?
> > >
> >         => Is there an "ACoA" in the draft ? If so it's a typo.
> >         I don't really understand your question. In extended mode the mobile
> >         node uses the MAP's advertised address as an alternate-CoA, oh I
> >         see what you meant by ACOA !
> >
> >         So I still don't get your last statement. The source address in the
> >         IP packets is the LCoA. The address shown to the appliccations
> >         is the Home Address. The address that the CN/HA has in their
> >         binding cache is the alternate-CoA (MAP's address).
> >
> >         Have I confused you more ?
> 
> Not at all, but let me rephraze. The question is which address would the MN use as its
> ACoA, the _home_ address of the MAP _or_ the onlink (LCoA) of the MAP?
> 
	=> In Extended mode, the MN sends packets using 
	its LCoA. In basic mode it can do the same unless
	instructed otherwise as er the P and I flags in rev 3 
	of the draft that Claude announced.

> > > If a MAP is serving as a mobile AR you enforce that it must advertise its and all
> > > MAP options available. Does that imply that the 'preference' is specific here?
> > >
> >         => The preference is either configured in the MAP or a default
> >         behaviour that varies with loading ...etc.
> >         Each MAP can have its own preference value independantly from
> >         other MAPs
> >
> 
> or a default behaviour that varies with loading ...etc.
> 
> 
> This is as vague as the statement in the draft...could you elaborate please? In fact
> that brings me to a whole new question
> with respect to my study of your scheme.
> 
> 1)There is no mention about how the preference metric is regulated and by what entities.
> Is it dynamic or static?
> 
> 2) Does the preference and distance metric work for different modes? Does one override
> the other?
> 
> If you have a preference metric and you opt for a map with the lowest preference, then I
> feel that your load balancing goes out of the window. All
> MN will get the lowest preference and a single MAP is guaranteed to always pick the same
> MAP. This is the one with the lowest pref.
> 
> What are the reasons imposing preference over distance?
> 
	=> I agree that we should show ways of setting the 
	preference. However one could argue that the same is 
	required for the HA in MIPv6. But you do have a point
	and it should be addressed for both.

	Perhaps a separate draft addressing both would be good.

> >
> > > Further (page 20, top statement) you state that this would allow the MN to obtain a
> > > new topologically correct RCoA. Do you really mean RCoA or CoA (i.e. LCoA).
> > >
> >         => We mean RCoA. The RCoA is the address provided by the MAP, regardless
> >         of which mode it operates in. So for Basic mode the RCoA is the
> >         address that the MN forms on the MAP's subnet. In extended mode
> >         the RCoA is the MAP's IP address.
> >
> 
> No RCoA is provided by MAP... MAP only provides a prefix and does DAD as far as I can
> tell from your protocol spec. This is not the same. I think it would be correct to state
> in your draft that the ACoA may take two values: an RCoA and the MAP's IP addr (I trust
> LCoA). I think this is better and leaves no space for ambiguity.
> 
	=> Ok. But we will use RCoA for both modes just for simplicity
	and state that RCoA can be used as a src address with basic 
	mode but not with Extended mode.

> >         => For the same reason you need HMIPv6 at all. Reduce signalling
> >         and help speed up the handover by updating a node close
> >         to the MN.> 
> >
> 
> Objection ! Speculative...If the MR acts as the closest MAP, I fail to see why the MN> 
> should choose the "further" (i.e. higher MAP in the routing hierarchy) so as to register
> its home addr and its CoA which is the IP address of the MAP that it has registered with
> (ie the closest one :)
> 
> In fact that creates exactly the pitfall that you argue against for RegReg: the creation
> of a routing hierarchy (two level for a single MR). Consider:
> Packets arrive to the "further" MAP; these are decapsulated and the B. Cache find that
> needs to send them to the CoA for that MN which (hey...) is..the _next_ MAP (level 1
> reached). This MAP will receive the packet and check the routing header to find the
> final dest the MN home addr. Encapsulate and send over to MN (level 2 reached). Do you
> agree?
> 
	No. The path between the MAP and the MN in the mobile 
	network case MUST include one of the MRs as the last hop or
	as an entry point to the mobile network.  This is not 
	an HMIPv6 restriction, the same is valid for a MN connected 
	to an AR. Just replace the MR with AR.

	My objection to the approach mentioned in Reg6, is that
	the traffic is _forced_ to go through the mobility 
	aware routers and there is no need for that.

> > Anyhow we've dicovered
> >         that there is a need for the network to inform the MN
> >         whether the use of RCoA is possible or not.
> >         We added that in the draft and Claude will post
> >         that on the INRIA web page soon.
> >
> 
> Fine...that however proves that you need to improve your spec further...what I am trying
> to say here is that
> the solution that each side proposes has got its merits, weaknesses, and may be open to
> further improvement (as with anything in life :)
> 
	=> Have a look at rev 3.

> This is to say that RegReg can come up with another autoconfig scheme for the routing
> hierarchy that decouples BU signalling and caters for
> single points of failures. This can also be expressed as "we are supplying a detailed
> supplement to the draft that solves this problem" which is
> just as good as your statement. What we need to make sure is understand that everything
> comes at a price. Complex protocol and signalling for
> really awkward mobility situations that can become the norm, or protocol simplicity for
> the base case and addition of optimization that again
> bring complications to the signalling design...I cannot see a clear cut choice to any of
> the two options.
> 
> I feel that the group would benefit infinetely if the specs merge...
> 
	=> "Merging" is not a goal. The goal should be to highlight
	what's missing in the current draft (HMIPv6) and if that 
	missing fuctionality is stated somewhere else then merging 
	makes sense. So far we haven't been given a good technical
	reason. The complexity of mobility management as you mention
	above does not imply the need for a multi-level hiearchy.
	It is solved with the single level one in HMIPv6.

> >
> > > If you have load balancing effected which RCoA do you send back to the HA?
> > >
> >         => Load balancing is done by the MAP, you only need to send
> >         one RCoA to the HA. Did you mean something else ?
> >
> 
> Well I cannot see the rational behind the load balancing being done by the MAP. Do you
> mean that a MAP will elect another MAP to forward encapsulated flows from different CNs.
> 
	=> No. Maybe load balancing s a bad name. Perhaps 
	we should call it something like "Per-connection or Per-flow
	movement". It is about moving a connection/flow to another
	interface. Using the MAP (a router in the visted network)
	seems reasonable for the same reasons that a BU to 
	a local anchor point is required.
	So the MN "moves" one connection while using the 
	same MAP.

	Thanks for your comments,

	Hesham

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 20 Mar 2001 14:09:16 +0100

>         It is solved with the single level one in HMIPv6.

I agree with Hesham...

Actually I do no mind merging if that makes sense technically.
What is the goal of the merge?
If there is an other proposal tomorrow will we have to merge too?

We should merge only if this makes sense technically otherwise we might
end up with a monster because the 2 approaches are quite different ....

A better approach might be:
- define the requirements
- evaluate HMIPv6 and Regv6 against these requirements
- and then decide whether it makes sense to merge or not...

I think this is the only way to make some progress...

regards,

Claude.

--

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

---

From: Theo Pagtzis <[email-masked]>
Date: Tue, 20 Mar 2001 11:10:33 -0800

Hi Claude,

> If there is an other proposal tomorrow will we have to merge too?

The issue that the WG has been looking over the RegReg and HMIP drafts
is, undoubtedly
hierarchical mobility, whether this is called regional, hierarchical,
tree-base n-ary, foo, for me (the other could comment further)
it is the same notion/idea.

Having read both drafts numerous times, I can see that one can fit
within the other if you wanted. Both you guys know that, I trust.

So to me it seems that the all-essential purpose is to get a strong
specification about hierarchical/regional (or regional/hierarchical just
in case one assumes that I am in favour of one of the two) mobility.
This is much better instead of trying to knock out each other as to who
has the a better spec. Both specs keep changing so much that they keep
the door of ambiguity and partiality wide open.

Instead of trying to knock the specs out individually, it seems to me
that it is in the in the interest of the community, and on the long run
of the hierarchical mobility, if the authors of both specs work
together, a single _well written_ spec comes out and becomes the object
of progress for the working group. Both specs today have had ambiguities
in their writing and I am sure we could spend the next 3 months trying
to understand what the authors intend to cover in the spec.

If a proposal comes out tomorrow as you stated, then I think that the
MIP WG is mature enough to evaluate its grounds for existence and if
need be merge the good ideas and their respective authors to the draft.
To me this is the fundamental reason why the constituency is called a
WORKING GROUP (emphasis on the word group). It is not about
individualism, be it a single individual or a company. This way
contribution to the group is much more comprehensive and focused, rather
than statements of authority....

The question is not whether we want to merge that too, but whether (if
the solution is neat) we are strong enough to admit that other people
can contribute nice solutions too, towards a better solution space, such
as hierarchical/regional mobility.

I think the above provide a sound justification for merging spec
solutions,

> end up with a monster because the 2 approaches are quite different

the two approaches are quite different???? it depends on one's
definition of difference..... :)

> - and then decide whether it makes sense to merge or not...

Open the requirements box for hierachical mobility...

    what is it really...?   In a nutshell.. to provide a local
instantiation of the HA near the MN. How near...??? there can be a
measure for that

of course this needs to be secure, fault tolerant, low signalling load,
blah blah blah..

the rest of the so called "requirements" are just trying to make what
people preach about "DIFFERENT" schemes..

In all honesty....am I wrong here...???   :)))

Theo

UCL / Mobile systems