IP over FDDI comments

[Steve Deering <[e-mail]>]

I regret that I will not be able to attend the IETF meeting in Florida,
but I have some comments on IP-over-FDDI that may contribute to the
discussions there.

First, I'd like to include an earlier message I received from Brian Cashman
and my reply, neither of which showed up on the general mailing list.

    From: [e-mail]:

	I want to make one more observation before I forget. As we all know
	single MAC stations can attach to either ring. The implication of this
	may not be obvious and should be mentioned as a warning in RFC 1103.
	Namely, if you use a single subnet address for the (dual) ring then
	you'll have stations on the same subnet that can't communicate. If you
	assign different subnets to each ring then you must have some sort of
	gateway for the two rings to talk (a dual MAC dual attached station
	could serve this function).

    From: Steve Deering <[e-mail]>:

	Brian,

	Exactly right.

	Something similar occurred to me too, since our discussions last week.
	The case where a single IP subnet number has been assigned to both
	rings and not all single-MAC hosts are on the primary ring *could*
	be handled by placing a MAC-layer bridge between the two rings.
	This is just like bridging two Ethernets to form a single subnet.
	It would seem to have the effect of forcing a permanent "virtual
	wrap" of the two rings, but it's not that bad -- the address
	filtering function in the bridge would keep each ring's local
	traffic confined to that ring.  On a real wrap, the bridge's
	spanning-tree algorithm would detect and do the right thing, though
	possibly not as fast as some might hope.  You might still need some
	way to distinguish secondary ring ARPs from primary ring ARPs if you
	want dual-MAC hosts to be able to do link-layer multiplexing; I'd
	have to think about that some more.

	So now I see three "legitimate" models for integrating an FDDI LAN
	into an IP internet:

	(1) Each ring (i.e., primary and secondary) gets its own IP subnet
	number.  If single-MAC hosts are connected to different rings, they
	can communicate only via an IP gateway (which may be, but need not be
	implemented in a dual-MAC host on that LAN).  Regular-old ARP works
	with no changes, regardless of wrap/thru state of the LAN.  A single
	TCP connection between two dual-MAC hosts cannot exploit both rings
	to get 200Mbit throughput -- all load sharing must be done above the
	IP layer.

	(2) The entire LAN (i.e., both the primary and secondary rings) is
	assigned a single IP subnet number, and all single-MAC hosts must be
	connected to the primary ring.  Dual-MAC hosts have a single IP
	address for both MACs, and they run a distinct flavor of ARP on the
	secondary ring to find other secondary MACs (and to avoid confusion
	when the rings wrap).  Dual-MAC hosts can exploit the secondary ring
	to double the throughput of a single TCP connection.  Single-MAC
	stations need no modifications.  All IP broadcasts and multicasts
	are sent on the primary ring only.

	(3) The entire LAN is assigned a single IP subnet number, single-MAC
	hosts may be connected to either ring, and there is a MAC-layer bridge
	between the two rings.  An IP broadcast or multicast may be sent on
	either ring (but not on both) -- the bridge will relay it to the other
	ring.  It's not yet clear (to me, anyway) how ARP should work to favor
	same-ring communication when possible, but allow cross-ring
	comunication when necessary, and to allow link-layer multiplexing
	between dual-MAC hosts.

Model (1) is the one that Vernon Schryver has advocated.  Model (2) is
my favorite.  The recent proposal from Doug Hunt and Carol Iturralde
addresses model (3), but *without* the link-layer bridge.  I'm not
very comfortable with the Hunt/Iturralde proposal because it allows for
a sort of "semi-partitioned" IP network, in which not all hosts can talk
to all others.  It places funny constraints on the placement of IP
gateways (e.g., you mustn't have two single-MAC gateways attached to
different rings, each advertising reachablility to the same IP network),
and it destroys the semantics of IP broadcasts and multicasts (e.g.,
a broadcast from a single-MAC station only reaches some of the hosts.
Should dual-MAC stations send each broadcast on both rings?  If so,
other dual-MAC stations will end up receiving unwanted duplicates.)

The Hunt/Iturralde proposal defines two new flavors of ARP (distinguished
by a ring identifier) for the two rings, and provides backward
compatibility by allowing Ethernet-style ARP to also be used on the
secondary ring.  My proposal is similar, except that I advocate using
*only* Ethernet-style ARP on the primary ring, and a new flavor of ARP
(identified by different ether-type or different OP codes) on the
secondary ring.  My scheme is a little simpler, because it eliminates
the backwards-compatibility handling, such as sending old-style ARP
when a new-style ARP fails to get an answer.

It would be nice if the ARP extensions were not FDDI specific.  Paul Koning
and I have discussed how this might be applied to the general situation
of "multi-rail" LANS, for example, connecting a bunch of hosts to
multiple Ethernets for increased reliability and/or increased throughput.
The way I would do this is to use old-style ARP on rail #1 (for
compatibility with single-rail-only hosts), and the new flavor of ARP
on rails #2 to #n (with the rail number included in the new-style ARP
messages).  If the reason for multi-railing were reliability, more than
performance, it could be further enhanced by connecting all the rails with
link-layer bridges -- that would allow a host to continue to communicate
with any other host even if its interface to rail #1 failed.

I hope these comments are of some help.  Have fun in Tallahassee!

Steve