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

Re: Thoughts about layering multi-addressing



It is clear that the priority is that the shim provides multihoming support for unchanged ULPs

The question is: after the shim is available, wouldn't it make sense to allow modified ULPs to have a richer signaling with the shim?

I mean, in this scenario, the shim is still used to provide some basic features for multiaddressing support, like the shim protocol is used to securely exchange the address set available for each end, for instance, and perhaps the path exploration procedure of the shim can be used to identify available alternative paths. But shim capable ULPs could actually do some functions that they would perform more adequately, like failure detection more adjusted to their own vision of what a failure is, or enhanced referral support (including all the address set in the referral)

I concur.

Additionally:

To me it looks like the (currently available) locator set is a property of a host and not of a connection; locators are meant to denote topological locations in the network, anyway. Hence, architecturally, locator set management seems to belong to the networking layer, i.e., IP.

We have traditionally taken care of path properties at the transport. Now we are moving some of this functionality to the networking layer, which may be the right direction in the very long run. However, IMHO we should aim for a conservative approach where we try to keep the shim as simple as possible, and keep the path property discovery at the transport layer.

In some way we seem to have two contending goals here:

1. keep locator sets at the IP layer, as a locator set is a property of a host and not a connection, and

2. keep path property discovery at the transport layer, as it has traditionally been done, separated from IP

However, I don't consider these to be that incompatible; anyway, we can have joint data structures that allows this distinction to be kept. Something like Dave's and Avri's CELP, or maybe what Brian alluded. The flip side of this is, of course, that this breaks the layering abstraction, somewhat. Consequently, I think that in the very long run we should reconsider where to place the traditional transport functionality; my gut feeling is that we may need to split it into path-dependent and connection-dependent parts, separated by a multi-addressing layer.

So, it looks to me that we are facing something like the following steps:

1. Minimally intelligent shim, one primary locator, unchanged
   transports

2. Shim as in #1, richer interface between shim and ULPs,
   shim-aware transports being able to use multiple locators
   at the same time

3. Further research on the proper new location(s) of traditional
   transport functions in the stack

#2 and #3 are clearly research at this point of time, and outside the scope of the WG charter. As I wrote in my first message in this thread, I would very much see running code or simulations in that space; without that we'd be driving in the dark.

However, I am worried that we may be trying to jump directly to #3 and design too much functionality to the shim. KISS vs. over- engineering, if you will.

--Pekka Nikander