Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: stds-802-3-hssg@xxxxxxxx*Subject*: RE: WWDM vs. 10Gb/s serial*From*: pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)*Date*: Wed, 12 May 1999 13:45:53 -0700*Sender*: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx

>Date: Wed, 12 May 1999 11:07:29 -0700 >To: elg@xxxxxxxxxxx (Ed Grivna) >From: Paul Bottorff <Paul_Bottorff> >Subject: RE: WWDM vs. 10Gb/s serial > >Ed: > >Granted if you know the state of the scrambler, the polynomial, and can insert data in sequence with the scrambler state, then a pattern of at most 2N bits will zero it, however these assumption are based on full knowledge and access to the PHY by the source of data. > >If anything goes it is much easier to break the PHY by jamming a screwdriver on the logic lines or pulling the wires out of the box. > >Cheers, > >Paul > >At 12:50 PM 5/12/99 -0500, you wrote: >>Hi Paul, >> >>You misinterpreted what I said (or at least what I was trying to say). >>Your referenced process to clear out a scrambler is correct, however, >>what I stated was that all it takes is on the order of 2n bits to clear >>it out, IF (an important if) you hit the scrambler with the correct >>set of bits. In other words, if I know the PRESENT STATE of the scrambler >>register bits, I can calculate a sequence of 2n bits which, when fed to the >>scrambler WILL clear it out. In reality this may only require n bits, >>but its been a couple years since I went through the excercise. >> >>So, for any given state of the scrambler there is always a set of n bits >>which will clear it out. >> >>-Ed Grivna >>Cypress Semiconductor >> >>> >>> Ed: >>> >>> The 2n bits is wrong. To zero out a scrambler of order n, you need a >>> pattern of (2**n - 1) bits. For instance, lets consider the seventh-order >>> frame synchronized scrambler that is being used by SONET. The pseudo-random >>> sequence generated by the scrambler repeats itself every (2**7 - 1 = 127) >>> bit periods. Since the pseudo-random output of the seventh register is >>> XORed with the payload data, a user could transmit a pattern that >>> continuously repeats the 127-bit pattern from the seventh register of the >>> SONET scrambler. When the pattern from the seventh register is aligned with >>> the 127-bit pattern from the malicious user, the line will see an all zeros >>> pattern. >>> >>> So, to zero out the scrambler, the user >>> 1- must know the order of the scrambler and its polynomial >>> 2- must have access to the whole payload envelop >>> 3- must use a pattern of (2**n - 1) bits generated by the polynomial >>> 4- must repeat its pattern enough until it gets in phase with the output >>> of the scrambler >>> >>> Paul >>> >>> At 07:06 AM 5/11/99 -0500, Ed Grivna wrote: >>> > >>> >> >>> >> Mick: >>> >> >>> >> It is 1 / (2**70) for randomized data. A properly designed scrambler system >>> >> produces completely random line data independent from the data being >>> >> transmitted. A constant string of zeros or any fabricated packet can be >>> >> encoded but the line data will still random. >>> >> >>> >> Paul >>> > >>> >The problem is we are not dealing with randomized data. With reference >>> >to a "properly designed scrambler," I can guarantee you that given >>> >any scrambler based on a polynomial of degree N, you can zero it out with >>> >the correct string of around 2N bits. This is not boasting or >>> grandstanding, >>> >this is mathmatical fact. The SMPTE scrambler polynomial has a high order >>> >term of x^9, and it can be cleared with two characters of data. >>> > >>> >This doesn't say that scrambling can't be used. But it does mean that >>> >a long polynomial needs to be employed to reduce (not remove) the >>> >probability of zeroing out the scrambler. The longer the polynomial, the >>> >greater the latency of encode and decode, and the longer to re-sync if >>> >it gets confused by bad data. Also, the longer the polynomial, the greater >>> >the error propagation; i.e., a one bit error in the serial stream will mess >>> >up more characters before its effects have propagated out of the descrambler. >>> > >>> >The basic SONET polynomial has a high order term of only X^7, while the ATM >>> >srambler is X^43+1. The SONET scrambler can be cleared quite easily, while >>> >the ATM scrambler is quite difficult to clear. The protocol overheads in >>> >these interfaces contain data that will keep the scrambler seeded, it is >>> >the associated data field that can clear it out. >>> > >>> >Then you have the issue with the lack of special characters. With respect >>> >to the 802.3 signal stream, yes scrambling has been used before, but at the >>> >physical layer there has always been a mechanism to indicate non-data >>> >signalling; i.e., a five level code where four levels are used for data >>> >and the fifth is for signalling. >>> > >>> >This is difficult in an NRZ stream unless you change the stream from >>> >character based to add an overhead bit every so many characters. The >>> >telcos use this ALL the time. In a T3 system they add 1 bit out of >>> >every 170 for synchronization and framing. >>> > >>> >Regards, >>> > >>> >Ed Grivna >>> >Cypress Semiconductor >>> > >>> >> >>> >> At 03:50 PM 5/10/99 -0700, Mick Seaman wrote: >>> >> >A string of 70 zero's does not have a 1/2**70 chance of occuring. >>> >> >Zeros and other particular repeating patterns are really much more common >>> >> >than that, as a look at carefully initialized memory will show. There >>> should >>> >> >be no restriction on transferring memory maps on any other particular data >>> >> >around. >>> >> >Any statistical argument has to very carefully assess assumptions as to >>> >> >distribution and independence of variables. >>> >> > >>> >> >Mick >>> >> > >>> >> > >>> >> > >>> > >>> > >> >>

**Follow-Ups**:**Re: WWDM vs. 10Gb/s serial***From:*Mike Dudek

- Prev by Date:
**RE: Proposed WAN vs. LAN Terms (Ethernet HSSG)** - Next by Date:
**Re: scrambling vs block coding** - Prev by thread:
**RE: WWDM vs. 10Gb/s serial** - Next by thread:
**Re: WWDM vs. 10Gb/s serial** - Index(es):