Some Thoughts on Multihoming January 26, 2000 Key Multihoming Observation #0: "TANSTAAFL: There Ain't No Such Thing As A Free Lunch" Multihoming is something that is done to provide *benefits*. Those are not *free*. There is a *cost* for them, and a multihoming design has to think about *where* and how much those costs are. JTW Principle: - The best design minimizes the overall cost of providing those benefits. JNC Corollary to the JTW Principle: - It is best if one can allocate the costs so that the entities which benefit from the multihoming are the ones to bear the cost. Multihoming Classification Observation #1: There are many different potential *goals* one may have for using multihoming, e.g.: - Reliability - Load balancing - More optimal paths - etc Depending on what one is trying to use multihoming *for*, this may make a lot difference to what mechanism(s) (see Obervation #0 about "cost") it makes sense to use. Multihoming Classification Observation #2: When multihoming is used to provide *reliability*, there are (at least?) 3 different levels of potential capability available. Those 3 classes (in what appears to me to be the increasing order of difficulty) are: - Allow new outgoing connections - Allow new incoming connections - Keep existing connections open Again, depending on what level of capability one wishes to provide, the mechanism used may differ. Multihoming Classification Observation #3: There are 3 different multihoming scenarios which are worth distinguishing when one considers mechanisms: - A site (i.e. collection of hosts, networks and interconnecting routers) which has multiple links to the rest of the world - A host (without embedded router) which is connected to multiple networks - A host (without embedded router) which has multiple names (i.e. addresses) and/or interfaces to a single network These differ enough in fundamentals to possibly need different engineering approaches to handle them. Multihoming Mechanisms: There seem to be two main mechanisms available to deal with the problems of the multi-dimensional capability space called "multihoming". The first is to use a variety of different addressing (i.e. names with topological significance) strategies (e.g. different addresses), and the second is to use the routing (i.e. make the routing system bear some of the cost of providing a given multihoming-based capability). Even considering just the current capabilities in the naming and routing areas, the complete space of desired capabilities, and potential mechanisms to produce them, is too large to detail here. (E.g. for the robustness/site case, there are three obvious one: - assign two addresses to all hosts in the site - assign addresses from one provider's space - assign "portable" addresses from neither provider Note that the latter two require 'support' from the routing, and the former does too in some sense, in that people have to know which address to use at any time.) My contention, however, is that the "optimal" solution (and I mean not just most cost-effective, but also cleanest, least kludgy, etc) to the large space of multihoming "problems" involves extra capabilities in two different areas: - identity/location separation - a better routing architecture I don't have time/energy to explore (across many capabilities/mechanisms) how each of these helps, but suffice it to say that while I believe that either one by itself helps to some degree, the best solutions occur when one has both available.