Path: utzoo!attcan!uunet!bu.edu!bu-it!kwe
From: kwe@bu-it.bu.edu (Kent England)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Multi-homed hosts and parallel networks
Keywords: multi-homed hosts, host naming, efficient routing
Message-ID: <58816@bu.edu.bu.edu>
Date: 14 Jun 90 18:32:41 GMT
References: <1990Jun13.213400.299@ultra.com>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@bu-it.bu.edu (Kent England)
Organization: Boston University
Lines: 46

In article <1990Jun13.213400.299@ultra.com>, shj@ultra.com (Steve Jay) writes:
>... Have there been any
> discussions on how IP can cope with multi-homed hosts and (semi-)parallel
> networks, such that traffic automatically takes the "best" path between
> hosts?
> ...
> I put "best" in quotes for a reason.  It may be considered better to have
> some traffic between B & C go over the ethernet rather than the faster
> network.  You may not want to clog up the fast network with the tiny
> packets generated by rlogin, but ftp data connections should be on the
> fast network.
> ...
> The issue is not how to route an IP packet once an IP addresse has been
> selected.  The issue is, how to decide what interface (and which network)
> to use when there is more than one choice...
>
> I'm not looking for "clever" ways to assign names to IP addresses.  I'm
> looking for ideas which might challenge some of the basic IP concepts,
> like names being associated with interfaces instead of hosts, and routing
> decisions based on a name specified by the user/application.  Have these
> issues already been discussed anywhere?  A quick look at the RFC index
> didn't help me.
>
> I'm looking forward to benefiting from the accumulated wisdom on the net.
>

        You might want to consider use of the Type of Service bits
in IP.  We are at the point where we will soon have some new routing
protocols deployed in the Internet which can support TOS routing.

        I noticed TOS coming up a lot at the Pittsburgh IETF meeting
and I did not get the feeling that very many people agreed on what
TOS meant.  Perhaps our wisdom accumulates more like dustballs than
pearls.  Now, if
you can figure out what TOS means according to the "accumulated wisdom"
of the IETF, you might be able to modify your applications to use TOS
with, for example, OSPF routing.  If you don't want to be compliant with
our accumulated wisdom, you might be able to use TOS as you please to
define parameters such as latency, packet size, or even dollar cost.

        You might also have a look at the Open Routing work.  Policy
based routing has a slightly different point of view, but it might
be able to subsume your concerns, on a longer timeframe than TOS routing.
Start with Dave Clark's RFC 1102 and Debra Estrin's RFC 1125.

        Kent England, Boston University