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

Re: shim design vs mobility/renumbering

Pekka Savola wrote: 
Hi,

This may be an obvious thing, but possibly worth bringing up explicitly..

When I read the specs, the obvious architectural approach taken by the shim6 approach -- not defining a separate identified name space -- has most implications in particular on renumbering and mobility.

In particular, especially with mobility, the locators are expected to become obsolete in a relatively frequent basis. As the ULID is tied to the locators, this has a couple of implications:

 1) what to do when the locator used for ULID has been removed from
    the node (permanently)?

 2) in particular, what to do in the circumstances are such that
    the locators get assigned to other hosts?

 3) specifically, then what if the host wants to communicate with the
    host which was given its previous locator, if the locator is
    still used as ULID?

For a site multihoming solution it might be able to assume the apps could continue using the old ULID as long as it works.

The WG certainly needs to decide to what to recommend on these points.
I guess it depends on the probability of the identical IP address being assigned to another host when the prefix is reassigned.

However, for mobility ("frequent renumbering") I doubt this would be sufficient. But having to change the ULID would defeat the purpose of IP mobility, so that's unacceptable. The sessions can't be changed to use a different ULID either (without changes to the transport protocols), so that's a no-go.

For mobility, if we are assuming that peers need to be able to contact the mobile host using some fixed or slow changing IP address (something that can be placed in the DNS, or registered with SIP, etc), then you naturally end up with the need for the host having some locators which are more stable than others. The more stable locators would be like MIP Home Address, and the less stable ones like MIP Care of Addresses.
And you'd have something like a Home Agent responsible for tunneling packets addresses to a home locators to one of the care of locators.

Applying the shim to that type of mobility is conceptually simple; just restrict the ULIDs to being the home locators.

So, from the mobility perspective, a solution like HIP is better.

AFAIK HIPs approach to mobility is architecturally isomorphic to MIP in that a fixed point is used in order to handle the case when both endpoints move at the same time, as well as providing a reasonably stable locator for initial contact. There used to be a name for what is architecturally similar to the Home Agent, but draft-ietf-hip-mm-01 now just says:
In these
situations there is a need for some helper functionality in the
network. Such functionality is out of scope of this document

*If* HIP can provide a mechanism to dynamically lookup up HIs/HITs in the future, there would most likely still be a need for such helper functionality, because it isn't likely that a system which can scale to Internet scale for these lookups, can also handle hosts that move and need to change their registered locators every few seconds.


Thus I think need benefits and issues around a stable identifier name space which is not tied to the IP addresses are quite different than the issues around mobility at the IP layer. Stable identifiers would help with renumbering, assuming there would be a lookup system that can scale to Internet size, but tracking the hosts movement is a different kettle of fish.

   Erik