Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Nomenclature for RTFC in 10GbE

At 7:42 PM 99/7/28, Brian MacLeod wrote:
>Some clarifications below.

>>I suspect you are correct.  In my nomenclature, a "link" is bidirectional,
>>having two independent fibers, and connects NICs to hubs.  It seems to me
>>that when one speaks of a link in GbE, it's the path from NIC to NIC (via
>>an unnamed hub); the hub is assumed.  In any case, we will need to arrive
>>at a common and self-consistent nomenclature.
>802.3 generally defines "link segments" which are symmetrical and are at the
>lowest level.  In other words, there is (mostly) no differentiation between
>types of link segment.  A link from a NIC to a switch is the same as a link
>between two switches and is the same as a link between two NICs by which I
>mean a link from NIC A to NIC B without any other device in the middle.
>Generally, there is no definition of link as between two NICs with a switch
>in the middle.  The definition used in 802.3u was
>"1.4.110 link segment:  The point-to-point full-duplex medium connection
>between two and only two MDIs.

OK.  Understood.

One implication is that fault tolerance is only for those systems having at
least one switch.  There are options in RTFC where two such switches are
directly connected (with no intervening two-headed NIC bridge), yielding
one large logical ring spanning the NICs attached to all connected
switches.  This is described in RTFC Principles of Operation under the
rubric "dumbbell" rings or topologies, if memory serves.

>>Is 10GbE expected to have hubs, or will all links be physically point to
>>point between pairs of NICs?  One would expect that there will be hubs in
>>10GbE as well, as inability to handle anything but pairs of NICs would be
>>pretty limiting.
>Up to 1 Gbps speed, there has been two modes of operation written into the
>standard: half-duplex and full-duplex.  At the time we started the 1 Gbps
>work, there was no standard full-duplex mode of operation (that came in
>March 1997 with 802.3x) so we felt compelled to include half-duplex
>operation.  Practical experience is that no one (in my personal knowledge)
>is building any half-duplex equipment at 1 Gbps.  Since we now have a
>full-duplex component to the standard, we could craft a 10 Gbps standard
>that is only full-duplex.  I suspect this is what most participants want so
>we might save ourselves the bother of the half-duplex work.
>Hubs are generally shared devices using half-duplex operation so following
>my previous opinion, I expect 10 Gbps to be an all-switched environment with
>no hubs.

I recall the debate.  Full-duplex is what I would favor as well.

>>So, my mental picture of 10GbE has been a star topology, with a hub in the
>>center and the NICs at the points of the star, with duplex fiber-optic
>>links connecting each NIC to the hub, one link per NIC.
>I agree, except that the hub changes to a switch.

Actually, there are RTFC switches as well (to support cut-through routing),
but rostering is indifferent to the distinction between hub and switch, so
I spoke only of hubs.  In the 10GbE world, it will then be NICs and
switches, and the following paragraphs can be translated into 10GbE-ese by
replacing "hub" with "switch":

>>In RTFC, one has the same number of NICs as before, but there are two (or
>>more) hubs, each hub having its own star of links to those NICs.  Each NIC
>>now has multiple duplex ports, one per hub.  The whole affair, containing
>>NICs and hubs, is called a "segment".  Bridges between segments are
>>two-headed NICs, one head per segment, even if the bridge NIC happens to be
>>physically colocated with a hub.
>>If one of the NICs is connected to only one hub, and nothing is broken,
>>rostering will cause that NIC to be included in the segment, and thus to be
>>accessible to other NICs.  This behaviour is automatic.  If a NIC having
>>only one hub connected breaks or loses contact with that hub, rostering
>>will isolate that unfortunate NIC.  This behaviour is also automatic.