RE: [802.3ae_Serial] B1 Parity and CID test pattern
Bruce,
Ben is correct. There was originally some misguided text in D3.1 implying that the CID field was overwritten after the WIS Transmit process and restored to the original J0/Z0 configuration prior to the WIS Receive process. Tim Warland presented a much cleaner test pattern methodology that formed the basis for D3.2. The CID pattern is intended to be part of the B1 calculation; in fact, the D3.2 text specifically states that CID-related errors (as well as other errors) shall be detected via B1. This would not be possible if the CID pattern were somehow excluded.
If, after reading D3.2, you still have the impression that the CID pattern is hacked on to the Z0 bytes and restored at the receiver, then I - as editor - must take responsibility for not conveying the intent properly. Perhaps a statement, to the effect that the CID pattern must be included in B1 calculations during both transmit and receive, would be useful? If so, I'd appreciate it if you could submit a comment against D3.2 when the comment period opens.
Best regards,
- Tom Alexander
WIS Scribe
-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Wednesday, August 15, 2001 8:20 AM
To: Nepple Bruce
Cc: stds-802-3-hssg-serialpmd@xxxxxxxx
Subject: Re: [802.3ae_Serial] B1 Parity and CID test pattern
Bruce,
Where did you get the information that the CID was "hacked"
onto the SONET frame rather than inserted into the frame
generation and made part of the B1 parity calculation?
Is this lifted from a presentation or email thread? I
don't recall seeing this as part of Tim Warland's draft
document.
Regards,
Ben Brown
Chair of Serial Jitter Test Patterns AD-HOC
"Nepple, Bruce" wrote:
>
> I am arriving a bit late in the game. I've tried to
> reconstruct the history of the jitter test "stuff"
> from the archives, but there is precious little
> information there.
>
> It appears that the current implementation of the WIS CID
> jitter test pattern is "hacked" onto an existing
> SONET frame, and depends on the receiver having knowledge
> of the "default bytes" in order to replace the CID locations.
>
> Rather than create a separate framing/deframing mechanism
> to insert or remove CID pattern bytes without affecting
> parity, I would rather just make use of existing
> framer resources (in my multi-protocol environment).
> Why can't the CID bytes just be part of the legal WIS
> overhead, rather than "hacked" on to an existing frame?
>
> The whole idea of filling those bytes from different
> resources (avoiding parity logic) and then replacing
> those bytes upon reception to make parity work seems
> like extra work. I'd be interested in knowing the
> rationale behind that decision.
>
> Thanks
>
> Bruce Nepple
> Network Elements, Inc.
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------