Re: OFC revived; 2.5 Gbit Ethernet
Jonathan,
I think your solution is a good one. Maybe OFC
has finally found a place in our lives if we choose
to use it in a WDM multichannel system.
However, every time I contemplate multichannel WDM
systems I am confronted with a couple of nagging
issues with which I still grapple:
1) If we decide on a WDM standard, why would we not
want to use it with the present 1.0 Gbit/s systems?
2) If we go ahead with a 4 channel WDM system, it
could conceivably operate at 4.0 Gbit/s with the current
GbE standard components, save the VCSEL and WDM filters.
3) The WDM standard could be evolved separately from
the next generation 10GbE serial standard. This way,
we could immediately upgrade the capacity of today's
LAN and provide a path to 40 Gbit/s capacity when we
finally reach agreement on a 10GbE standard protocol.
The way I understand the multichannel proposals currently
in play is perhaps lacking. I would welcome a different
perspective. Why bother splitting the data up into four
channels, transmit them over different wavelengths, and
then recombine them at the far end unless there is some
compelling reason to do so?
The only reason I can supply is there must be some aspect
of this data which binds it together logically. The only
one I can imagine might be the need to send wide data words
at high rates from server to server.
A modern processor might have a 1GHz clock and 32 bits
in a word. This would imply the usefulness of a 10Gb/s
chip-chip interconnect. Bus architectures commonly in use
today such as PCI do not require 10Gb/s bandwidths.
I assume therefore, we must be preparing 10 GbE for a
development in backplane technology such as Infiniband.
Some additional contradictions stir:
1) Most network engineers from Ethernet backgrounds would
not admit the driving force behind a network proposal is
genetically a point-to-point backplane extension.
2) The parallel transfer of data from server-server
sounds too much like Fibre Channel. This statement
might provoke true network engineers like Ethernet guys,
but one cannot avoid the comparison to the early Fibre
Channel goals.
The alternative answer to why we need 10GbE WDM networks
is perhaps to provide additional transmission capacity
for 1GbE service over existing infrastructure. I see
this need very clearly as one which must be addressed
in the short term.
Errata:
1) Inasmuch as we choose to call a 4 channel WDM system
operating at 2.5Gb/s a 10Gbit network, we may also term
a 10 channel WDM network operating at the basic GbE
1.0Gbit/s rate a 10Gb network. In the case of the latter,
we might hesitate to term it 10GbE because we would not
have to evolve any new standard for Ethernet protocol.
2) Why is it we insist on terming 4 channel WDM systems
at 2.5Gbit/s a 10GbE network? Aren't we really working
on 2.5 Gbit Ethernet with a 4 channel WDM overlay? How
could a 2.5X increase in the basic serial line rate not
be considered an evolutionary improvement similar to the
2X Fibre Channel systems presently sampling?
The above is especially true when one considers the genesis
as a chip-chip or backplane interconnect. I guess 2.5GbE
doesn't sound as good as 10GbE.
3) What have we learned from attempts to use parallel data
communications over distance (HIPPI, SCSI, etc.)?
I think the answer to the above is parallel architectures
do not scale well - especially when switching.
Summary:
So, in summary, I must agree with you there is a low burden
Open Fiber Control solution available to us for WDM network
proposals. I also think we should develop WDM for the LAN
environment independently from the protocol.
Best Regards,
Pat Gilliland
patgil@xxxxxxxxxxx
-------------------------------------------------------------
At 09:18 PM 2/26/00 -0600, you wrote:
>
>Patrick,
>
>Summary: Yes, open fiber control could simply (less than 50 gates) and
>easily reduce transceiver costs for WDM, PAM, and Parallel transceivers (and
>maybe even serial). Perhaps, now that the transceiver companies have figured
>out how difficult the budgets are to achieve with low-cost optics, it is
>time to address this in greater earnest.
>
>We have discussed this strategy a number of times at various HSSG meetings.
>It was, in point of fact, first brought up by yours truly at the "call for
>interest meeting" last March. It is certainly not popular with transciever
>companies. Even so, personally, I don't think that people are being quite
>fair here. One does not need to utilize timing at all to make "OFC" work.
>Each of the colors or fibers (i.e., each laser) can be designed to be
>inherently laser safe (NOFC-like). You just can't turn on more than one
>laser in the multi-laser system until the link is closed. It is very simple
>logic to design. Dead simple. For a four laser system, you potentially
>increase the optical power usable by 4X or 6 dBm. Since timing would not be
>used, distance and latency would not enter into the equation (even for
>multihop systems like FC-Loop; a 10 Gig FC-loop! Yikes!).
>
>In the case of PAM-X, the Rx must be able to correctly detect the lowest
>level signal. This lowest level signal could therefore easily be used to
>check for a closed link. The system would simply not use the higher power
>signals required by the coding until the closed link was detected. This, for
>PAM-5, would also allow a 4X or 6 dBm effective increase in power in the
>link.
>
>The funny thing is, if the SERIAL transceivers used this same trick (yep it
>would probably add a Mux and resistor divider to the DC control circuit on
>the laser and modify the sense circuit on the light detection circuit, which
>is likely needed anyway due to the long run lengths of zero's being
>proposed), even the serial guys could fix some power budget problems.
>
>Like with the original OFC based system, this additional power and power
>budget can be traded off AGAINST higher sensitivity and tighter
>manufacturing tolerances, thereby reducing the cost of the transceiver (the
>original goal for FC-OFC). While it is true that FC threw out FC-OFC, my
>recollection was that this was primarily due to the TIMING problems
>encountered running FC-Loop over optics, which is not a problem here
>(remember, no timing). It is also the case that there were companies that
>did not meet the timing specifications because they forgot to include the
>turn-on and sense delays of the analog portion of the laser's DC control
>circuit to the overall timing equation. After shipping product this way for
>a fair period of time, these companies asked the FC group to go back and
>modify the timing numbers to allow them to "meet spec." The problem was not
>with the original specification or the concept, but because we had to find a
>set of numbers that several companies could all say they met. Not being able
>to find any, we had to revamp the entire definition to prove that equipment
>in the field would continue to work. It does. The last issue with FC's OFC
>was the 10 second max time delay for turn on. This was, again, an artifact
>of the use of timing and, again, not an issue here.
>
>None of these issues apply to the scheme above (and below).
>
>I believe that some WDM advocates do not like the idea of using OFC (this
>non-timed version) because the losses in the Tx optical system (laser to
>fiber path) are sufficiently severe that they can't run the lasers any
>hotter anyway. For some of the parallel fiber people, some interesting
>mathematical games are played in order to argue that the light from the
>multiple fibers don't quite add.... Both of these seem to be rather
>short-sighted positions.
>
>jonathan
>
>> -----Original Message-----
>> From: owner-stds-802-3-hssg@xxxxxxxx
>> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Patrick Gilliland
>> Sent: Saturday, February 26, 2000 4:46 PM
>> To: stds-802-3-hssg@xxxxxxxx
>> Cc: kardontchik.jaime@xxxxxxxxxxx
>> Subject: Re: open fiber control in PAM-5
>>
>>
>>
>> Jaime,
>>
>> No doubt there are schemes to overcome any
>> difficulty such as the Class 1 power limitations
>> imposed by the IEC and CDRH.
>>
>> The option of using Open Fiber Control does not
>> seem to be particularly attractive. During the
>> FC-0 days of Fibre Channel it was used to overcome
>> the same Class 1 power limitations.
>>
>> A great deal of time and effort was spent trying to
>> create an OFC protocol which would guarantee multi-
>> vendor interoperability. We even had an OFC working
>> group to address these issues. The FC-0 equipment
>> which is still in service today is in many cases, not
>> interoperable because of OFC timing incompatibilities.
>>
>> This is especially true at longer distances, as the
>> latency requires longer and longer OFC related outages
>> as the interested parties wait for the other partner to
>> respond with the correct sequence of pulses before they
>> initiate full duty cycle transmission. I believe Fibre
>> Channel correctly eliminated an obstacle to interoperable
>> systems in FC-1. Sometimes simple is better.
>>
>> Best Regards,
>>
>> Pat Gilliland
>> patgil@xxxxxxxxxxx
>>
>> -----------------------------------------------------
>>
>>
>> At 02:55 PM 2/22/00 -0800, you wrote:
>> >
>> >Hello 10G'ers,
>> >
>> >I would like to eliminate another misconception
>> >regarding the serial at 5 Gbaud vs the 4-WDM
>> >at 1.25 Gbaud approaches in PAM-5: the supposed
>> >signal power advantage of the serial approach
>> >due to eye-safety limits.
>> >
>> >I will show below that the launched power
>> >PER CHANNEL in 4-WDM can be safely set at the
>> >same level as the total launched power in the
>> >serial approach, due to the redundancy in
>> >its receiver (no single point of failure).
>> >
>> > ---> Since the launched power level per
>> > transmitter of the serial and 4-WDM
>> > approaches will be the same, 4-WDM will
>> > enjoy a 12 dB advantage in SNR, due to
>> > its receiver bandwidth being 4 times
>> > smaller (same signal power, much smaller
>> > noise power).
>> >
>> >The key is in the "open fiber control" method.
>> >How do I envision this method in the PAM-5
>> >specific case ?
>> >
>> >In a serial approach using, for example, 850 nm
>> >lasers, the maximum launched power is -4 dBm.
>> >
>> >In a 4-WDM approach we could use the following
>> >procedure to keep the launched power PER CHANNEL
>> >at -4 dBm (for a total launched power of +2 dBm)
>> >and still ensure a safe-eye environment:
>> >
>> >1) When a near-end node is connected to a link
>> >and powered-up it will transmit a signal at -4 dBm
>> >using only ONE transmitter and keep the other
>> >three transmitters off. In this way the eye-safety
>> >limit is satisfied.
>> >
>> >2) The near-end node will remain in this state
>> >for as long as it does not sense a signal in
>> >any of its four receivers.
>> >
>> >3) Also the far-end node, when it is powered-on,
>> >will do the same: transmit on only one channel
>> >using the maximum -4 dBm allowed for eye-safety
>> >considerations.
>> >
>> > It makes sense to use only one transmitter
>> > after power-up to send a life signal to a
>> > potential partner on the other side of the
>> > link, just to conserve power consumption
>> > as long as there is no answer from the other
>> > side.
>> >
>> > Which transmitter should be used for sending
>> > this life signal ? For reasons that will
>> > become obvious later, the best choice is
>> > the transmitter that sends the PAM-5 encoded
>> > TA symbols, following the nomenclature of
>> > the 1000BASE-T standard (*)
>> >
>> > For the following, remember that each
>> > receiver has four channels, named RA, RB,
>> > RC, RD.
>> >
>> >4) If any of the two partners senses and recognizes
>> > a signal in its RA-receiver, it will go
>> > to the next state of its state machine: it
>> > will switch-on the other three transmitters and
>> > begin transmitting IDLES, with each transmitter
>> > using a full -4 dBm launched power.
>> >
>> > The advantage of using only the TA-transmitter
>> > during the first step of establishing a link
>> > becomes now obvious: in the 1000BASE-T,
>> > the RA-receiver has the capability to
>> > synchronize the receiver descrambler to
>> > the transmitter scrambler, by just using
>> > only the information embedded in the
>> > transmitted TA-symbols.
>> >
>> > Hence, there is no danger that the receiver
>> > will confuse a spurious signal with the real
>> > signal: it has to be able to synchronize
>> > its descrambler and verify that the
>> > synchronization is indeed correct using just
>> > the embedded information in the transmitted
>> > TA-symbols, in order to make a positive
>> > identification. Without this identification
>> > it will not switch 'on' the other three
>> > transmitters.
>> >
>> >5) During normal operation, if any partner suddenly
>> > ceases to receive signals on ANY of its four receivers
>> > (that are tuned to four different wavelengths)
>> > during more than, say, 1 millisecond, it will switch
>> > back to its previous state, that is, shut off
>> > three transmitters and send a life signal
>> > using only one transmitter at - 4 dBm. This
>> > might be the case, for instance, when a
>> > technician opens the link at any point
>> > between the two partners.
>> >
>> > (the loss of signal is easier to detect than
>> > the existence and validation of a real signal,
>> > hence, a very simple and robust no-signal-detect
>> > circuit may be used).
>> >
>> > Notice that the four receivers, that are tuned
>> > to four different wavelengths, must malfunction
>> > in order to miss the "open link" event. It is
>> > this redundancy in a 4-WDM system that allows
>> > the use of a total + 2 dBm launched power during
>> > normal operation.
>> >
>> >The above procedure could also be a replacement of the
>> >PHY Control State Diagram, Figure 40-15, of the
>> >1000BASE-T standard (with further details to be added
>> >later), since in 10 GbE we do not need the concept of
>> >"master" and "slave" and loop timing used in 1 GbE
>> >(that was used there to eliminate the Echo and NEXT
>> >interferers).
>> >
>> >(*) during normal operation, after the link has been
>> > established, a transceiver sends through its four
>> >transmitters quartets of PAM-5 symbols, {TA,TB,TC,TD},
>> >with TA = {+2,+1,0,-1,-2} and similar for TB,TC,TD.
>> >
>> >Jaime
>> >
>> >Jaime E. Kardontchik
>> >Micro Linear
>> >San Jose, CA 95131
>> >email: kardontchik.jaime@xxxxxxxxxxx
>> >
>> >
>> >
>> >
>>
>