shj@ultra.com (Steve Jay) (06/14/90)
Fast networks (FDDI or UltraNet) are being installed in parallel with
existing ethernet networks. Hosts are becoming multi-homed (more than
one IP address) for reasons other than IP routing. 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?
Consider the following combination of networks and hosts. Network 1 is
ethernet, Network 2 is something much faster. Hosts B and C are connected
to both networks, host A is on network 1 only, and host D is on 2 only.
1 2
+-------+ | |
| | | |
| A +--------+ |
| | | +------+ |
+-------+ | | | |
+-------+ B +---------+
| | | |
| +------+ |
| +------+ |
| | | |
+-------+ C +---------+
| | | | +------+
| +------+ | | |
| +--------+ D |
| | | |
| | +------+
How can it be arranged so that IP traffic between any two hosts travels
over the "best" path?
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.
One of the reasons that this isn't easy is that names and IP addresses
refer to specific interfaces, not hosts. In the above configuration,
host A has one interface (call it A-1), host B whas B-1 and B-2, host C
has C-1 and C-2, and host D has D-2. Normally, in this situation, the
system administrator would alias the name B to B-1 or B-2 in /etc/hosts
(or equivalent). This leads to very inefficient routing. If B is aliased
to B-2, then IP traffic between A and B could end up routing through host
C, rather than using the direct A-1 <-> B-1 path. If B is aliased to B-1,
traffic between D and B could go through C.
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. It's possible that the "best"
choice will vary during the life of one connection, based on packet sizes
and network loading.
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.
Thanks in advance.
Steve Jay
shj@ultra.com ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130 "Home of the 1 Gigabit/Second network"
kwe@bu-it.bu.edu (Kent England) (06/15/90)
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