Re: Does Ten-Gigabit Ethernet need fault tolerance?
Roy,
At 6:02 PM 99/7/18, Roy Bynum wrote:
>
>I have a question? Your RTFC flooding algorithm sounds a lot like the
>restoration
>algorithms that have been proposed for DXC traffic restoration in the telephony
>industry. These have not been used because of the complexity of constraints
>introduced in designing the architecture. This might work in very simple
>systems,
>but I have reservations about successful implementations in large, high
>bandwidth,
>enterprise networks.
I am not familiar with these proposed DXC algorithms. Could you perhaps
provide a URL?
The RTFC technology is limited to hub and spoke systems with paths to and
from the NICs, which can be wired into a logical ring. This would include
fast ethernet, gigabit ethernet, and ten gigabit ethernet, unless I am
greatly mistaken. RTFC heals links independently of one another, so there
is no need for an ubercontrol layer, keeping things simple.
>In doing economic modeling, it was discovered that using simple L1
>working/protect
>restoration link services actually cost less to implement in large complex
>architectures. Nodal failure is more often better handled at higher layers.
>
>In addition, simple L1 restoration implementations are easier to maintain for
>not-so-technical people. Part of the reason for the success of 802.3 is the
>simplicity of maintenance. The success of 10GbE will be dependent on a
>continuing
>of that simplicity.
RTFC recovers wthout involvement of higher layers or software, in much less
than one millisecond. The actual value is two or three ring tour times,
where a ring tour time is 50 or 60 microseconds in a shipboard system.
Assuming five ring tour times and 60 microseconds, the total recovery time
would be 300 microseconds worst case for such a system. Smaller systems
will recover faster. One advantage of such short recovery times is that
it's practical to keep the software in the dark -- all they will see is a
few lost packets, which higher layers will simply resend. Bottom line --
introduction is simplified because the huge base of existing software can
be used as is, and there is nothing for users to understand (or
misunderstand). If we play our cards right, it will just work.
For the record:
>The ring tour time is the time it takes an update packet to circumnavigate
>the segment. The
>rule of thumb to compute ring tour time is allow 670 nanoseconds per node
>(NIC) plus
>5nanoseconds per meter of fiber, remembering that each node-hub cable
>contains two
>fibers, so a 33-node segment with 125-meter node-hub cables has a 63.4-mS
>ring tour
>time. Two thirds of this ring tour time is the propagation time of light
>in the fibers.
The other basic point I am making is that 10GbE NICs and hubs could have
fault-tolerance provisions built in at insignificant added cost if done
now, allowing users to upgrade when needed without having to discard the
users' investment in 10GbE NICs. Obviously, to achieve fault tolerance,
the users will have to purchase at least twice the hardware, but it can be
more-or-less standard-issue 10GbE hardware, a great benefit to users and a
significant technology differentiator in the market. No forklift upgrades.
Joe
>Thank you,
>Roy Bynum
>MCI WorldCom
>
>Joe Gwinn wrote:
>
>> Jonathan,
>>
>> At 2:22 PM 99/7/16, Jonathan Thatcher wrote:
>> >
>> >A question and a suggestion:
>> >
>> >1. Are you suggesting that Fault Tolerence is a requirement for 10 Gig
>> >Ethernet or for all Ethernet? Or, if FT is added to 10Gig Ethernet, is
>>it of
>> >any particular value if 10, 100, and 1000 BASE-* don't have it?
>>
>> I am suggesting fault tolerance as an optional enhancement for 10GbE only,
>> mainly because it's early enough in 10GbE's standards development timeline
>> that FT could be included without pain, if the committee so desires.
>>
[snip]