Re: scrambling vs block coding
- To: "Michael M. Salzman" <msalzman@xxxxxxxxxx>, stds-802-3-hssg <stds-802-3-hssg@xxxxxxxx>
- Subject: Re: scrambling vs block coding
- From: pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)
- Date: Wed, 12 May 1999 11:51:02 -0700
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
A good summary of the debate. Here are a few comments and questions.
Paul A. Bottorff
Director Switching Architecture, BAL
Nortel Network, Inc.
At 09:27 PM 5/11/99 -0700, Michael M. Salzman wrote:
Hi all, The many cogent arguments about this subject highlight the requirements differences between long haul and LAN applications. Although we have reason to expect that the packets sent along the LAN would emerge unscathed onto the long haul network, there is no fundamental requirement for those packets to be encoded and modulated in the identical fashion. The LAN environment, whether SX or LX will require Phy's that are cheaper, simpler and more robust. Long haul applications on the other hand may derive an overwhelming cost advantage from the scrambling approach. Thus the interconnection gateway between the LAN and the Long Haul would have the SX/LX phy's on the one side and some kind of a long haul port on the other. That port could be a direct phy - for those cases where the signal simply enters a dark fiber, or it could be a port of a DWDM mux, that would insert the signal at a particular wavelength. <<<<
The port of the DWDM may either be direct to wavelenght or could be a SONET TDM. To make this transition easiest and most general it is desirable to have a data rate equal to the SONET payload. The payload rate of a SONET channel is 9.620928 Gb/s which I believe is close enough to 10 Gb/s to be considered 10 Gb/s (though I don't like it 8/10 encode sets the baud rate at 12.026160 Gb/s). This makes it impossible to carry the 8/10 encode through the SONET envolope forcing a new encode at the boundary. Do you expect to build 10 GigE based on 8 Gb of data for a 10 Gbaud line?
At the same time, a dual phy approach, leaves a few issues unresolved. Among the benefits of the block coding approach is the ability to pass pseudo-data elements back and forth on the link. These capabilities are most required for the long haul, where a quick recovery of the link is most desirable. Furthermore, the ability to differentiate the level of the link problem in a long haul application is important. It could be an amplifier failure, or a sync loss, or total transmitter failure. Furthermore, would it not be desireable to enable loopbacks at a low level in the long haul link in order to idenitfy the location of the failed component? Such schemes are often done outside the payload. One answer is that 10 Gig links are likely to travel over a WDM infrastructure, providing its own physical fault isolation, hence a separate mechanism would not be required. The flip side is that a block code with control codes would provide that extra measure of protection. <<<<
I don't see why we wouldn't provide special codes in a scrambled line used to provide all the Ethernet distributed management. Scrambling does not prevent distributed line management.
Frame based approaches for managing the link would require a full scale PHY and MAC at each device. Finally, retiming, regeneration muxing and switching devices along the way would benefit from the more rapid clock and error recovery of a block code. It would reduce the demands on them. <<<<
Again, anything which can be done in a block code could be done with a scrambled code even if the exact technique for line encode is different.
Michael Salzman Director of Business Development
Phone 408-871-4075 Lan Systems Group
Home 408-867-5164 150 Knowles Drive
Fax 408-871 4102 Los Gatos Ca 95032
Cell 408-829-4425 msalzman@xxxxxxxxxx