Revisting the compromises - transmission bandwidth of the WAN compatible PHY
Rich,
Not to revisit too many of the issues with the compromises that have
already been made all in the same message thread, I will respond to your
response one issue at time. This thread is to set the story straight about
the bandwidth hit on the WAN compatible PHY.
You said:
"The first order bandwidth hit to the WAN PHY is the fault of SONET
framing. The second order hit is due to the block coding PCS. However, it
is the block coding PCS that allows the direct mapping of Ethernet to SONET
at the physical layer. The current "cell tax" of ATM is a much worse
bandwidth hit than 64B/66B for Packet over SONET.
Note that the LAN PHY doesn't seem to have any problem with the same PCS,
and is capable of supporting a full 10 Gbps data rate, transporting greater
than 7% more data than SONET. This provides customers interested in
connecting their LANs over typical MAN/WAN distances with a cost effective,
straightforward and significantly higher bandwidth transport... and a clear
decision point."
Actually you are wrong about the order of the bandwidth hits to the WAN
compatible PHY. A first order bandwidth hit was taken by the WAN
compatible PHY because of the fixed SONET signalling rate. The SONET
signalling rate that was proposed for the WAN compatible PHY did not allow
it to adjust to higher signalling rates to compensate for inefficient
coding schemes. The second order bandwidth hit was the reduced function
SONET sync frame overhead that removed additional bandwidth. The third
order hit to the WAN compatible PHY was when a compromise forced an
inefficient coding scheme on the data stream, based on block coding,
similar to fiber channel.
The original proposal for the WAN compatible PHY used HEC frames to replace
the IPG and preamble and then one for one scrambling. This was a very
efficient coding scheme. The original proposal did not introduce any third
order bandwidth hits. Because the original proposal replace the IPG with
distinct frames, the number of HEC frames between the data frames could be
reduced and thus compensate for the first and second order bandwidth hits.
A similar mechanism will need to be employed to remove IPG idle bytes in
the existing compromise in order to compensate for the IPG expansion of the
open loop control of the transfer rate. In fact, some of the third order
bandwidth loss can be compensated by compressing the IPG before it gets
block encoded.
As for the LAN PHY not having bandwidth hits, it is mater of
prospective. The data transfer rate only remains constant for the LAN PHY
because of a first order bandwidth hit on the signalling rate. In order to
maintain the transfer rate using a block coding scheme in the PCS, the
signalling rate must be increased. That is the reason that a scheme that
is more efficient than the original 8b/10b was introduced. Is a mater of
fact, the original block coding is so inefficient that it is only used for
multi-wavelength or multi-fiber PMD proposals. ( I admire the subterfuge
by which that fiber channel has been maintained as a prominent coding
scheme in P802.3ae. My hat is off to you. :-) )
Thank you,
Roy Bynum
(I will take up other threads at a later date.)
At 01:23 AM 7/18/00 -0700, Rich Taborek wrote:
>Roy,
>
>As you might expect, I just love a good dog fight :-)
>
>Break Link and Remote Fault are bastions of Ethernet link management and
>generally all that is needed to manage an Ethernet LAN link. OAM&P is
>associated
>with SONET/SDH, provides Break Link and Remote Fault support along with a
>myriad
>of functions and features, most of which are not applicable to Ethernet.
>
>Besides, LSS is capable of supporting both Break Link and Remote Fault for LAN
>PHY links used in LAN environments as well as OAM&P for LAN PHY links used in
>MAN/WAN environments.
>
>Please see my additional comments below:
>
>Roy Bynum wrote:
> >
> > Ben,
> >
> > I may start a dog fight with this comment but here goes.
> >
> > I question why there needs to be so much effort to insert "break link and
> > remote fault" when OAM&P functionality was the primary purpose behind the
> > WAN compatible PHY. There was a lot of argument about how to best go about
> > providing that OAM&P. There was a MAJOR compromise to split the PAR into
> > two distinct PHY logics, one with OAM&P and one without.
>
>There was never any PAR split. The HSSG merely added a WAN PHY objective to
>provide direct mapping from 10 GbE to OC-192c/SDH VC-4-64c
>
> > Now I am seeing an attempt to put OAM&P functionality into the PHY logic
> > that originally specifically excluded OAM&P. I voted against LSS because
> > the additional complexity in a LAN is not needed. If an implementation
> > architecture requires OAM&P, the WAN compatible PHY is available.
>
>The WAN PHY is deemed by some to be far more complex and costly than
>required to
>connect Ethernet LANs together without going through SONET equipment. Granted,
>these are greenfield applications. However, there are customers for
>Ethernet LAN
>PHY links beyond the LAN. The WAN PHY is neither intended as an Ethernet LAN
>link nor a SONET replacement. Its sole purpose is to facilitate the attachment
>of 10 Gbps Ethernet equipment directly to SONET.
>
> > There should not be any optical distinctions between the LAN PHY without
> > OAM&P and the WAN compatible PHY with OAM&P.
>
>I'm not sure what this statement implies. If it implies what I think it
>implies,
>the optics will be similar if not the same. Optical specs are likely to be
>different due to significant differences in coding schemes and data rates.
>
> > Given the major transfer bandwidth hit that was forced on the WAN
> > compatible PHY by a block coding PCS, OAM&P functionality is one of the
> > distinctions that provides customers with a clear decision point.
>
>The first order bandwidth hit to the WAN PHY is the fault of SONET
>framing. The
>second order hit is due to the block coding PCS. However, it is the block
>coding
>PCS that allows the direct mapping of Ethernet to SONET at the physical layer.
>The current "cell tax" of ATM is a much worse bandwidth hit than 64B/66B for
>Packet over SONET.
>
>Note that the LAN PHY doesn't seem to have any problem with the same PCS,
>and is
>capable of supporting a full 10 Gbps data rate, transporting greater than 7%
>more data than SONET. This provides customers interested in connecting their
>LANs over typical MAN/WAN distances with a cost effective, straightforward and
>significantly higher bandwidth transport... and a clear decision point.
>
> > I would recommend that the group take the failure of the group to
> > provide 75% support as an indication that this should be dropped and energy
> > spent on other things.
>
>To me this sounds like more of the same kind of FUD which resulted in an
>abstention vote 34% higher than the opposition vote in light of a more
>than 63%
>yes vote. Using the same logic, do you also recommend the Task Force abandon
>multimode fiber cable plants?
>
> > Thank you,
> > Roy Bynum
> > A customer
>
>Best Regards,
>Rich
>SPCA
>
> > At 11:20 PM 7/14/00 -0400, Brown, Ben [BAY:NHBED:DS48] wrote:
> >
> > >Hi,
> > >
> > >The LSS proposal was not initially accepted to be part
> > >of draft D1.0. The opponents of this proposal felt that
> > >this was too complicated a method for reporting Break
> > >Link and Remote Fault. Since I've heard many times on
> > >this reflector and in the meetings that, if a proposal
> > >is going to be shot down a substitute should be made to
> > >take its place, I'd like to request just such a substitute.
> > >
> > >Another thing to remember. According to Jonathan's
> > >schedule, this was the "last new proposals" meeting.
> > >I'll be interested to hear proposals for break link
> > >and remote fault reporting that do not include major
> > >new ideas.
> > >
> > >Thanks,
> > >Ben Brown
> > >P802.3ae Logic Track Chair
> > >
> > >--
> > >-----------------------------------------
> > >Benjamin Brown
> > >Router Products Division
> > >Nortel Networks
> > >1 Bedford Farms,
> > >Kilton Road
> > >Bedford, NH 03110
> > >603-629-3027 - Work
> > >603-624-4382 - Fax
> > >603-798-4115 - Home
> > >bebrown@xxxxxxxxxxxxxxxxxx
> > >-----------------------------------------
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com