Re: scrambling vs block coding

[pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)]

 Michael:

A good summary of the debate. Here are a few comments and questions.

Paul

Paul A. Bottorff
Director Switching Architecture, BAL
Nortel Network, Inc.
pbottorf@xxxxxxxxxxxxxxxxxx

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.
>>>>
> size=2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Michael  Salzman             Director  of Business  Development
> Lucent Technologies 
> 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