[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how mobile do we need to be (was Re: how mobile do we want to be)



Hi Avri,


El 23/03/2005, a las 7:36, avri@psg.com escribió:


On 22 mar 2005, at 17.22, Margaret Wasserman wrote:

At 11:05 PM +0100 3/22/05, Iljitsch van Beijnum wrote:
That would require some serious voodoo as these are nearly always managed by different entities. So essentially this would keep the problem the same but require wifi base stations and gsm/umts infrastructure to solve this and hide the complexity from the hosts. This isn't traditionally the way the IETF does things.

I was actually expecting that, to get this to work well, you'd need to purchase the 3GPP/802.11 roaming service from a single provider...

I don't expect this to be the case in all cases.

In my view of things there is definitely a case where L3 could reasonably be involved.

What I expect to happen is that a 3G/802 equipped device/node would move into a zone where 802 was possible and where at some point it could be connected to two or more providers at the same time, sort of multihomed. During this interval it could have separate addresses given by different providers. And as in any multihomed node it could chose which provider to use based on its own policy constraints. As it moved from one zone's prevalence to another or from one provider's area to another, the balance would change and different providers, and L3 addressing possibilities, could become available.

And while it is true that one could use the extensive machinery of MIP to make this work, it seems to me that using the multihoming shim's capabilities could be a lighter weight possibility. But while it is possible that support for this sort of movement could just fall out of the shims specialized for static and fixed multihoming,

I guess that we should keep in mind that SHIM will deal with _site_ multihoming, and not node multihoming
I guess that all this discussion is about host multihoming, which could benefit from mobility support


So, i am not sure how much sense it makes to demand mobility support in the site mutlihoming scenario, unless you are considering something like a NEMO, which has not been really the focus in the discussion.

I mean there is a lot of context and unstated assumptions here. I guess that we are here to provide a site multihoming solution. Then since the site mutlihoming solution recommended by the multi6 wg is based on a shim, now we are also considering to use it to provide host multihoming (which is already out of the scope of the SHIM imho) and then we want that the site mutlihoming solution also provides support to a mobile node.

I guess that this could be possible, but, i guess that the point is that those different problems don't have the priority for the people that have been working on multi6. I mean we have been working for a long time to provide a site multihoming solution, imho this should be top priority in this wg. Of course it would be nice that we could also provide node multihoming support and mobile multihomed node support, but these imho are not the priority here.

Besides, remember that we already have a mobility solution working but there is no site multihoming solution out there, and people are really waiting for this.

So, imho we should really focus in the site mutlihoming case, and of course we should keep a broad view in order not to do any _arbitrary_ choices that disable the usage of the shim for node multihoming and even mobility support, but this should not be the focus of our work now, and imho the support for mobilty should not be cosidered as importand the the real goal of this work, which is site mutlihoming support.

and just a final comment: i really don't think SHIM sill be a lighter weight option for mobility support, perhaps it may be attractive for other reasons, but not for being lighter.

rgeards, marcelo

I expect that support of a dynamic multihoming model, i.e. one with movement, might hold some gotchas. I would prefer to see us deal with these during the architectural and protocol design stage then to have to deal with them in the deployment stage when the solutions might end up as afterthoughts, i.e addon hacks.

One thing I am pretty sure is that if it is possible to coerce shims into doing dynamic multihoming, i.e. multihoming with movement, then someone will. Given that it probably will happen, it might be better to design for it.

a.