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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Mar 2001 18:28:39 +0100

Hello Theo, 

Sorry if another one of the authors already answered this 
but it's hard to know, given the list's current state. If someone
else answered then hopefully the answers are the same :)

Please see my response below

Regards,
Hesham

>    I would appreiciate if the HMIP authors could shed some light in some statements
> in the hmipv6-02 draft that got out recently.
> 
> 
> 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 ?

> 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

> 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.

> The
> reason I ask here is because you state that in the extended mode the MN is bound to
> use the mobile AR/MAP IP address.
> 
	=> Yes, this is to make sure it receives packets. 

> Also you state that the MN should send a BU to the (further ???) MAP to bind its
> Home Addr with the MR's CoA. 
> 
> 
> Can you explain why you need to do that? Do you mean
> 
	=> 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.

> by further, a MAP higher (upstream) in the routing hierarchy?
> 
	=> Yes.

> How can you possibly have location privacy if the upstream packets have as their
> source address the MNs LCoA. 
> 
	=> Which mode are you referring to now ? We don't claim location
	privacy for Extended mode, but for Basic mode you can use the 
	RCoA as a source address. That's how you get it.

> If you do not have the LCoA as the source address,
> then start praying over egress filtering.
> 
	=> If I pray, I usually pray for better things ;)
	MANY networks don't use it. 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.

> 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 ?

	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 16 Mar 2001 15:01:21 -0800

>         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?

>         Each MAP can have its own preference value independantly from

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?

>         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.

>         and help speed up the handover by updating a node close

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?

>         => If I pray, I usually pray for better things ;)

I am glad you do.. :)

>
>         MANY networks don't use it.

Very good assumption...tell that to the service providers, domain admins..... :))

> Anyhow we've dicovered

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 :)

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...

>         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.
Each CN needs to have an RCoA to send packets to. Each RCoA is being created by the
MAP prefix, . If an MN needs to register with a MAP, multiple MAPs distribute the
traffic load for a single MN (and as such need to receive traffic for different RCoA),
that means to me that you need two different RCoA. Otherwise please explain to me HOW
the MAP will force CNs to send traffic to another MAP.

Many Thanks

Theo