Re: IP over FDDI comments

[[e-mail] (Vernon Schryver)]

> From: Steve Deering <[e-mail]>
> Subject: IP over FDDI comments
> 
> 	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.

What happens when the ring wraps?  What would a bridge between the rings do
then?  Please recall that an individual station including any bridge or
concentrator cannot know when the ring has wrapped within any usefully
small time.  It can hope to compute a ring-map based on NIF's or something,
but that can take a long time, during which it has the wrong idea.

A bridge between the rings of a dual ring would do one of two catastrophic
things.  It would "melt" the ring when it wrapped, by continually
forwarding stuff from the "main" ring to the "secondary" ring, when in fact
there is only one ring.  Second, it would "learn" that single-attach
stations that are on physically on the secondary ring are on the primary
ring.  The first catastrophy would surely happen until the second
happened.  The second would not be fatal until the ring left WRAP, and then
the secondary-ring single-attach stations would be dead.


> 	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.

One additional advantage is that this scheme would allow single
attach stations on the secondary ring.  Putting single attach stations
on the secondary ring and wanting to do IP/FDDI seems sufficiently
unusual that I do not think this is a significant advantage.

> 	(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.

As I claim above, #3 (with the bridge) is not desirable.

> 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.

One could simply say that a legal IP/FDDI network does not include
single attach stations on the secondary ring, "solving" the problem by fiat.


I still favor #1.

Failing that, I favor a from of #3, with the single-attached problem
"solved" by fiat, but with a different ARP scheme than (I think) heretofore
proposed.  As someone in a discussion at SGI suggested recently, let's use
a FDDI frame with two ARP packets.  That is, dual-MAC stations would send
single FDDI frames containing a pair of 802.3 ARP packets, one immediately
following the other.  The first ARP packet contains the MAC address for the
primary ring, while the second contains the MAC address for the secondary
ring.  The first ARP packet in the FDDI frame has an ethertype, while the
second has either the same or a new type.

Older and single-MAC implementations on the primary ring would send
FDDI frames containing a single ARP packet.
Any station that wants to do IP on the secondary ring or to do load
balancing thus has all of the information necessary.

The main advantages of this ARP encapsulation is that
 1) standard BSD if_ether.c can be fat, dumb, happy, and ignorant 

 2) there are no funny cases to worry about in dual-MAC stations.
	You do not have to worry about sending 2 ARP packets, and
	cover the cases when one or the other should have been sent
	and understood by the receiver, but is lost on the fiber.

The 2nd problem has caused me to worry about all multi-packet ARP
schemes.  There seem to me to be a lot of cases to cover, and some
cases where a sub-optimimal answer is inevitible  (e.g. when the
new-fangled ARP packet between dual-MAC stations is lost in the fiber).


Vernon Schryver
[e-mail]