Re: Clarification on added B2/B3 bytes in WIS
I'm sorry that I couldn't attend the WIS review in Tampa due to the many
parallel breakout sessions. However, it seems that the direction to move
functionality such as B2 parity bytes into the WIS seems to fly in the
face of developing a simple Ethernet to SONET mapping. In my mind there
are two ways to specify the WIS overhead bytes:
1) Make them exactly like SONET;
2) Support only the minimum required to support the client, which is
Anything else seems to be neither beast nor fowl.
If the Task Force goes with #1, then there's very little work to be
done. Simply reference the appropriate SONET specs to insure
interoperability. If going with #2, then B2 bytes should stop at the
ELTE and are not applicable to the WIS. #2 would result in a cost
effective WIS by a significant margin.
Gordon Jacobs wrote:
> I would like to confirm my understanding of the B2 parity bytes
> added in the WIS overhead as per the motions in Tampa last week.
> Looking at SONET descriptions, each of the 192 B2 bytes represents
> the BIP parity of each of the 192 ST1s in the last frame, but
> Section Overhead is excluded, and parity is calculated before
> scrambling. As such the B2 parity bytes meet the following rules:
> 1. exclude columns 1,2,3 and include columns 4-90 in rows 1,2,3
> (i.e. excludessection overhead)
> 2. include columns 1-90 in rows 4-9, and as such,
> includes the B2 byte from the last frame, in row 5, col 1.
> 3. includes the path overhead (first B2) and fixed stuff
> (next 63 B2s) in the calculation for the SPE.
> Since the B2 bytes represent the BIP parity for the last frame,
> there is 2x storage required for the history mechanism. Why does
> show four 192x8 RAMS for hardware requirments to generate
> the B2 bytes rather than two 192x8 RAMS (current frame and
> last frame)?
> Finally, for the B3 parity byte, ANSI T1.105-1995 states that
> the B3 calculation excludes the fixed stuff bytes. For the WIS,
> there are 63 bytes of fixed stuff after each path overhead byte
> which are zero. Obviously these can't affect the parity
> calculation on Tx (since they are zero), but the ANSI doc implies
> that they should be ignored in the receiver (i.e. a bit error in
> the fixed stuff will not cause a B3 parity failure). Is this
> Thank you very much,
> Gordon Jacobs
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