Subject: Re: draft-ietf-pppext-sonet-ds-00.txt

From: [email-masked] (C. M. Heard/VVNET, Inc.)
Date: Sun, 23 Nov 1997 18:41:21 -0800

On Sun, 23 Nov 97 21:02:25 GMT William Allen Simpson
<[email-masked]> wrote:
> 
> > From: Stuart Venters <[email-masked]>
> > First the "Applicability" section. IMHO, (and given the benefit of 20-20
> > hind site,) I think you are solving the wrong problem.  While there may
> > be a need for an intra-campus Sonet spec, there is definitely a need for
> > a full wide area spec which is fully Sonet compatible.  Wouldn't overall
> > interoperability be better served if we gave up interoperability with the
> > original 1619 and cut over to some other scheme which is fully compatible
> > with the actual wide area Sonet installed base?
> >
> Where is this not fully compatible?  There have been no verified
> examples given where it is not....  Please be specific.

The I-D <draft-ietf-pppext-pppsonet-scrambler-00.txt> by Manchester,
Krishnaswamy, et al. was pretty clear about this, and I for one
find its conclusions hard to fault.  Based on a more conservative
analysis than theirs, I have concluded that ~538 IP datagrams filled
with 11 copies of the SONET scrambling pattern sent through an RFC
1619-compliant interface will have a better than 90% chance of causing
a string of 127 consecutive zero bytes on the SONET fiber.  At 155 Mpbs
it takes about 6.55 microseconds to transmit 127 bytes.  This is well
above the minimum value (2.3 microseconds) for the SONET LOS threshold.
Hence RFC 1619, owing to the lack of payload scrambling, is incompatible
with the specifications that the wide area SONET installed base is
required to meet.

>[ ... ]
>
> As I've mentioned a few times, it all comes down to the stability of the
> receive clocking design.  A bad design will have problems.

If the purpose of PPP over SONET/SDH is to take advantage of existing
infrastructure, then the PPP over SONET/SDH spec needs to be compatible
with the specs to which that existing infrastucture is required to comply,
even if in your judgement good engineering practice would dictate that
the equipment should be built to follow tighter specs.

> A simple and
> effective design, say an external clock running at 16 times the data
> rate, should have no problems at all....

This is a dandy way to locate bit transitions at low speeds.  Most
UARTS use it, as do DPLLs in some low- to moderate-speed HDLC devices.

But at OC-3 rates it would imply circuitry clocking at

   16 * 155.52 Mhz = 2.48832  Ghz

which is not so easy to do.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]