Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter proposal)

From: Simon Oosthoek <[email-masked]>
Date: Thu, 30 Mar 2006 13:51:00 +0200

Ben McCarthy wrote:

> In your 1st scenario, consider a MR providing an access network on a train,
> conceptually providing connectivity to possibly 100's of nodes. With the RO
> system you propose, every CN that every node is communicating with would
> have to be updated, every time the MR changed its point-of-attachment. This
> would result in having to perform something equivalent to the MIPv6 Return
> Routability test (not a particularly lightweight procedure) with every CN
> every time the MR picked up a new CoA. Then if you consider that the train
> could be tarvelling at a few hundred Km/hr and handing off relatively
> frequently, what you get is a lot of protocol overhead (Binding Update
> Storms) when roaming. And that's without taking into account the added
> complexity of a Nested Nemo scenario, i.e. if a PAN got on the train :).
> 

Of course, but I don't think it would be hard to piggy-back this update 
info in e.g. ACK packets returning to the CNs. And a train full of 
people is still only about 500 people, it would surprise me if there 
were more than 50 CNs active at any particular moment.

And then there's the L2/L3 mobility. In the next 2 years, up to 50% of 
the trains in NL are being fitted with APs and the access is being done 
via GPRS/UMTS. This requires no updates while moving, since the mobility 
is done at L2.

I suppose any kind of RO will result in more signalling overhead, it's 
not a free operation, but it may be possible to optimise...

/Simon

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 30 Mar 2006 10:23:59 -0800

> www.ist-magnet.org]

sounds pretty cool.

> In the first scenario, wouldn't it be enough to have the HA and MR 
> inform corresponding nodes of a "via router" that is the 
> actual care-off 
> address of the MR for the address inside the MNP? That way 
> the CNs can 
> always directly communicate with the MR and if that fails, 
> fall back to 
> the HA until it gets an updated VIA.

this is route optimization for NEMO, but one possible
way of setting up route optimization. this would require
modifications to the CNs.

> The second case is much different, being a VPN, it might be 
> desirable to 
> hide the physical location of the MR from the CN and thus it 
> would not 
> be desirable to RO that communication. A proxy-HA might be 
> interesting 
> here, but only if it is part of the same VPN structure. And I 
> think this 
> will still reveal something about the physical location of the MR.

this can be supported by NEMO Basic Support 
(RFC 3963). you dont need anything more.

Vijay