Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: scrambling vs block coding

Paul, you raise an interesting point, which concerned me as well.  The issue is the mismatch of rates between OC192 and a pure 10Gig payload. My Nietzschean answer at the moment is that the very question confirms the difference of requirements and perspective between the two applications.  A more satisfying answer will, I am sure, be forthcoming in the meetings.  Moreover, the framing of the packet within the transmission is an unsettled issue at this time.  Your question suggests a full sonnet frame, and I have heard suggestions ranging from Sonet lite, to no Sonnet frame.  I also accept your comment regarding the addition of codes to the scrambled output to allow some control mechanisms to operate.  I suppose that having done that, however, we lose some of the bandwidth improvement over a block code.
 
I have to also admit that you are exceeding the limits of my current knowledge on this matter.
 
On a more hairbrained level, I wonder if removing the old coax preamble from the payload would save enough bytes to effectively reduce the rate below the 9.6Gig required for Sonet?

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.
>>>>