For our best current understanding of the proprietary Nokia SDSL flavor see
this WWW page:

http://ifctfvax.Harhan.ORG/OpenSDSL/2B1Q/flavors/nokia.html

Being designed for Flavor B, the CopperRocket hardware is obviously not well-
suited to implement radically different SDSL flavors which use ATM instead.
However, wherever there is a will, there is a way, and we've managed to
implement reception and transmission of Nokia frames using the LC302 SCC in the
transparent mode.  This feat is implemented in the Nokia SDSL version of our IP
router, and the higher ATM and AAL5 layers are implemented purely in software,
i.e., "by hand".  It is clearly an example of what can be accomplished given
enough will, but NOT an example of good engineering practice.  Our solution
works OK at low data rates (up to 384 or maybe 768 kbps), but fails completely
at the higher Nokia SDSL speeds of 1152 and 1536 kbps.  The higher the SDSL
data rate, the more difficult it is for the CPU to perform all the necessary
processing in the allotted time.  Specifically:

192 kbps:	Works like a charm with the SDSL pipe saturated in either
		direction.

384 kbps:	Works reliably (no SCC overruns or underruns), OK with the
		downstream pipe fully saturated, but unable to utilise the full
		upstream bandwidth. The effective usable upstream bandwidth is
		about 208 kbps (26 kbyte/s) as measured by an FTP transfer.

768 kbps:	Similar to 384 kbps, but less reliable: SCC Tx underruns and
		SDSL down/up cycles are incurred occasionally when heavy packet
		load is presented in both directions at the same time. The
		effective usable upstream bandwidth is *less* than that at
		384 kbps because the higher interrupt and SDMA load steals even
		more cycles from the CPU-starved thread.

1152 kbps,	Unusable. As soon as any significant packet load appears in the
1536 kbps:	downstream pipe, a fatal SCC Tx underrun is incurred. The SDSL
		link is then re-established, but as soon as TCP retries, the
		fatal underrun condition recurs.

Aside from the speed limitation, this release has the correct implementation of
the Nokia flavor which has been tested and proven working on a real Covad line
at 384 kbps.  Release 1.0 contained an incorrect implementation based on an
incorrect understanding of the Nokia frame format; the latter was incorrect
because we had no real Covad SDSL line to test on, only back-to-back tests
against other CPE devices.

We also have a little debug utility called nokiadump.  It performs a bitpump
activation, then sets the SCC up to receive and transmit Nokia frames.  All
received frames are dumped on the console in hex while the transmitter keeps
sending hard-coded idle frames (frames containing 8 idle cells) to keep the
other end happy.  The utility can also perform quat alignment tests if a blue
wire is added to the board connecting the bitpump's QCLK output to the LC302's
CD1 input.  See the source code for further details.

Nokia EOC

We don't do anything with incoming Nokia EOC messages because we don't know
their meaning and we put a constant FF in the EOC octet of the outgoing Nokia
frames we transmit, but in order to aid further experimentation and reverse
engineering efforts we have implemented a conditionally compiled EOC dump debug
feature in the Nokia SDSL version of the HoR IP router.  See router.doc and
router-impl.doc for further details.
