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

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 15 Mar 2001 09:07:53 -0600

I had the same comment about the location privacy. One could say it provides
a little better location privacy but that's about it. They might know the
city or building that your in as apposed to a room.

-----Original Message-----
From: Theo Pagtzis [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 7:12 PM
To: [email-masked]
Subject: [mobile-ip] Some questions on Hierarchical MIPv6

Hi all,

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

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?

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

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
by further, a MAP higher (upstream) in the routing hierarchy?

How can you possibly have location privacy if the upstream packets have as
their
source address the MNs LCoA. If you do not have the LCoA as the source
address,
then start praying over egress filtering.

If you have load balancing effected which RCoA do you send back to the HA?

Regs.

Theo

UCL / Mobile systems

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Mar 2001 23:34:14 +0100

> I had the same comment about the location privacy. One could say it provides a little better location privacy but that's about it. They might know the city or building that your in as apposed to a room.
> 
	=> True. But the same goes for any IP adderss in the hierarchical
	IPv6 world. Right ?

	Hesham

> From: Theo Pagtzis [ <mailto:[email-masked]>] 
>    I would appreiciate if the HMIP authors could shed some light in some statements 
> In extended mode you state that the MN should use as CoA (ACoA) the IP of the MAP. 
> 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? 
> 
> 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). The 
> reason I ask here is because you state that in the extended mode the MN is bound to 
> 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 
> How can you possibly have location privacy if the upstream packets have as their 
> source address the MNs LCoA. If you do not have the LCoA as the source address,

---

From: James Kempf <[email-masked]>
Date: Tue, 20 Mar 2001 13:58:19 -0700

Theo,

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

Actually, I think you are wrong. I think one of the problems is that
the two drafts are based on some very fundamental differences in 
opinion about what the requirements are. 

Before the working group has agreement on that, I think it's useless
to proceed with a solution.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 21 Mar 2001 23:08:47 +0100

Sorry for the late reply.

> I also think that agreed requirements will help developing the  protocol
> tremendously.
> Unfortunately I don't know all the detailed history of the WG and thus I
> don't know what requirements were used as the base for the existing drafts.
> I'd like to list several requirements that seem to me a sort of minimal
> ones.
> 
> 1) Localizing signaling for intra-domain handoffs
> - Minimizing signaling traffic to HA or CN for intra-domain handoffs
> 2) Minimizing overhead on air-interface and MN
> 3) Reliability
> - Capability to provide connectivity continously to existing or new MNs
> visiting the domain in the case of intermediate node failures
> (the intermedia node would be MAP, GFA, RFA, etc.)
> 4) Minimizing service disruption period in the case of intermediate node
> failures
> 5) Scalability
> 6) Security
> 
	=> Agreed. I think we can also get some things
	for free (relatively!) like location privacy and 
	some level of support for Mobile networks.

> I'd like to point several issues for each proposal (RR, HMIP).
> 
> 
> HMIP:
> In my understanding, the HMIP proposal allows redundant or multiple MAPs
> covering a certain spot (or cell). I see several issues in HMIP regarding
> it. I assume a MN registers with only a MAP at a time.
> - Overhead to the air-interface due to MAP option advertisement
> As the number of MAPs increase, the overhead becomes larger.
> 
	=> We only expect two options at the most for reliability
	or overapping domains. This can be an overhead if RAs 
	are advertised very frequently, but that is not 
	the assumption we're making. The Fast Handoffs
	draft shows that this is not required for mobility.

> - Overhead to the MN
> MN needs to monitor the MAP option advertisement continously to know whether
> the MAP is alive even when the MN has not moved its location
> 
	=> The MN MUST monitor RAs and check if any changes 
	have taken place. This is already a requirement for IPv6
	and MIPv6 in general.
	I don't think this is a new requirement
	due to HMIPv6. Adding one more option will add
	more checks in the MN but I don't see another way
	of informing the MN that a MAP exists/disppeared.
	Perhaps you could suggest a different mechanism
	that we can consider.

> - Connectivity recovery time
> The MN needs to wait for the MAP option advertisements and then do
> re-registration to a new MAP, HA and/or CN. The MN should know the MAP
> option advertisement period and wait for a certain timeout period to find
> out the failure of the MAP. Obviously the advertisement period is related to
> the overhead to the air-interface and thus it is not easy to reduce the
> period.
> 
	=> Detecting a MAP failure can result in triggering an
	RA which does not include that specific MAP's 
	option. This does no require frequent RAs, instead 
	they are advertised only when needed. 

	The trigger can be based on any of the MAP discovery
	mechanisms or another protocol. 
	For example, In the dynamic MAP discovery case
	the MAP can advertise with short intervals, but 
	the ARs do not need to propagate that with 
	the same intervals. 

	Hesham

> ----- Original Message -----
> From: "James Kempf" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, March 17, 2001 2:02 PM
> Subject: Re: [mobile-ip] Some questions on Hierarchical MIPv6
> 
> 
> > >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...
> > >
> >
> > I'd like to second this.
> >
> > But first, I think there needs to be some agreement on requirements.
> >
> > jak
> >
> >
>