Long before my interest in SDSL grew into the present Open SDSL Connectivity Project, i.e., before it became such a big deal to me, my focus was much narrower. The only SDSL flavor I was concerned with (and the only one I even knew about) was Copper Mountain. I was living in an apartment in Escondido, California served by Pacific Bell CO ESCNCA01, and this being in the good old days before MCI/WorldCom had decommissioned the Rhythms DSL network, I had a Copper Mountain SDSL line from them. My goal was the same as present though: to connect a routed (not bridged) SDSL circuit to a router of my choice instead of the soapbox one.

For quite a long time I have had a number of gross misconceptions about Copper Mountain SDSL, and the main purpose of this public apology page is to acknowledge and clear them. The short summary in less technical terms is that CM was a far more decent company than I had originally thought, and it's very unfortunate that CM exists no more (at least as far as DSL goes).

Desiring to design and build my own CM-compatible CPE (either a reincarnation of or a replacement for Larscom CupreDSU), I had contacted CM asking them for what I thought they had provided to all other manufacturers of CopperCompatible CPE: the schematic for their SDSL bitpump circuit along with any necessary firmware files. I did not realise at the time that this circuit was an off-the-shelf chip (from Brooktree, then Rockwell, then Conexant) rather than a discrete circuit designed by CM, and that even the term bitpump originated from the chip vendor rather than CM.

Jack Chan from CM had quickly replied to me that they had used 8970 and 8973 chips from Conexant (documentation here), but this was all they could tell me. I was then quite upset at them not giving me more details, but in retrospect I now see that CM's answer was perfectly reasonable.

Perhaps the only thing I could fault CM for is not adding and this chip is all you need in order to connect to our SDSL lines to their reply about the bitpump chips. But it was also my fault that I hadn't pursued the project myself in a timely fashion.

The fact was, not only did Jack's reply name the 8970 and 8973 chips, he even had datasheets for them which he had offered to me if I was willing to accept large E-mail attachments (my 4.3BSD-Quasijarus mail servers creak and squeak in pain from those, so I have Sendmail configured to reject them), and had suggested that I go to the chip vendor for help with my design.

In retrospect, Jack's reply was totally reasonable by the standards of the engineering profession. It is the standard practice in the field of electronic engineering that chip vendors provide support for their chips. I had asked CM for a reference schematic for their SDSL bitpump circuit, and since (as I now know) CM had simply used the Brooktree/Rockwell/Conexant chip in the straightforward manner, it was totally reasonable for them to redirect my request for the reference schematic to the chip vendor. Perhaps that was what Jack had meant by not being able to assist me further.

One could argue that CM could have been a little more explicit about the details such as not needing a framer or ATM, their exact data rates, etc., but then again it was my fault that I hadn't pursued the matter actively at the time.

I had first started my exploration of SDSL in late 2004, and my first exchange with CM took place in early January, 2005. But then other things had happened in my life and I was completely away from the SDSL project until I suddenly had to reopen it almost a year later. My next contact with CM had not occurred until February, 2006.

If I had worked on the SDSL project in 2005 as eagerly as I had claimed I wanted to design and build my own SDSL CPE, I could have gotten the datasheets for the bitpump chips and thus acquired a basic understanding of the issues involved. I would have undoubtedly had more questions about the specifics of CM's SDSL flavor, but if I had been working on this stuff right then in 2005 and could have posed my questions to CM in a timely manner and in a short and concise form, I probably would have gotten the answers I needed.

One could also argue that CM could have told me about their startup sequence and CMCP, sparing me having to discover them through reverse engineering, but then (as I know now) CPE support for those things is optional, they are just nice frills. One could argue that since CM has given these frills to other CPE manufacturers, they should have given them to me as well, but it would have been reasonable for them to expect me to do my homework first, i.e., build a basic functioning unframed HDSL transceiver based on Conexant's reference design, and only then talk about enhancing it with bells and whistles (which are all software, no hardware changes needed).

But what has ended up happening instead is that 3 days after Jack had E-mailed me naming the 8970 and 8973 chips, my SDSL circuit was delivered using the bridging workaround. This compromise solution worked good enough, and as it happened, at the exact same time there were some other major things happening in my life (those of you who know me personally, think Yule-Imbolc of SE 43), and I had completely dropped the SDSL project for the time being.

The SDSL project had to be suddenly reopened in late 2005. Unforeseen life circumstances had compelled me to relocate to a different physical location, and the move had reminded me in a rude awakening manner that my bridging workaround was not a real solution, and that a proper solution was still to be developed.

The SDSL project reopened in late 2005 was an adventure, but not with CM. Instead it involved Conexant and Mindspeed. This affair took us into 2006, and only in February-March, 2006 did I engage in a dialogue with CM again.

By that time I was already aware of there being different flavors of SDSL/2B1Q, and of my new SDSL line from Covad being of the Nokia flavor rather than CM, quite different. But since at that time I was already thinking along the lines of what was to become the Open SDSL Connectivity Project, i.e., I cared about all SDSL lines and not just my own, I was still interested in the CM flavor, and I had asked Jack Chan once more about its details. I couldn't get any answers.

Part of problem may have been that some of my questions were badly incorrect (in technical terms), but the main problem was that it was too late. By that time Copper Mountain no longer existed as a DSL company, having been devoured by a cable company instead. Almost all of the original CM DSL people were gone.

Since then I have found out virtually everything there is to know about CM SDSL through reverse engineering, and only now can I appreciate just how good CM was compared to some other DSL flavors. My late realisation of CM's goodness is the main reason why I feel compelled to present this public apology.

My earlier misconceptions about CM SDSL

Here is the full list of what I have previously erroneously believed about CM SDSL, with corrections:

That CM used both ATM and frame-based encapsulations on the line

A lot of documentation refers to CM having used RFC 1483 encapsulation. Since this is an ATM RFC, the natural automatic assumption from this information alone is that the line carries ATM cells. It has turned out, however, that I had overlooked the word FUNI in all those places where RFC 1483 was mentioned in relation to CM SDSL. (I'll even admit that I had overlooked it because I didn't know what it was at the time.) Certainly any telecom engineer who claims to be capable of designing DSL CPE should know the difference between real ATM and ATM FUNI, so I readily acknowledge that it was silly for me to demand framing and encapsulation details from CM while not knowing such basics.

FUNI stands for Frame based User-to-Network Interface, the first word being the key. It's a frame-based interface, i.e., HDLC, not ATM cells. (August 2007 update: this page explains exactly what CM's RFC 1483 encapsulation is.)

In retrospect I realise how silly it was for me to think that CM or any other DSLAM would support both ATM and HDLC service models on the same line card. The two call for completely different hardware, so no DSLAM vendor in his right mind would build a single line card supporting both. It's one or the other, and in the case of CM it's an HDLC-framed bit stream.

That CM SDSL used HDSL framing

Looking back I really don't understand what made me believe so. The only documentation I had at the time was for the Brooktree/Rockwell/Conexant bitpumps (part of their HDSL chipset) plus some later chipsets like Orion and M289xx, and for some reason I had assumed that the configuration using a 6 ms frame and a 16 kbps overhead channel (what we now call Flavor H) was the norm, and that the unframed Flavor B was some weird exception. (The simple thought that the HDSL framer is really unnecessary in an SDSL application and that it would be extra cost had for some reason escaped me, although it would provide a few benefits.)

Thinking that what we now call Flavor H was the norm and considering CM to be the gold standard of SDSL in general (I didn't really know any other flavors at that time), I felt sure without a shadow of doubt that CM SDSL was Flavor H. (And since I still believed at the time that CM used both ATM and frame-based encapsulations, I had assumed that it then differentiated into Flavor HA and Flavor HB.) I was so sure of that belief that I was on my merry way to designing and building a CMSDSL-11 Q22-bus line card for my 4.3BSD-Quasijarus routers, using an RS8953B HDSL framer and implementing flavors HA and HB.

Oh boy, did I need a whack on the head on that one! If I hadn't been sidetracked by the monkey business with Mindspeed, I may very well could have ended up building that HDSL-framed CMSDSL card and then being stuck with a very pretty but absolutely useless hardware design: as I know now, HDSL framing was not used by CM and it may very well be that it was never used by any flavor of SDSL/2B1Q!

That the bitpump data rate had to be Nx64 or Nx64+16

The Nx64+16 formula comes from HDSL, and it would have been the expected bitpump data rate with Flavor H. With Flavor H an SDSL line carrying 384 kbps of payload would have run the bitpump at 400 kbps.

When I had finally started to doubt whether CM SDSL indeed used HDSL framing, my next question immediately was is the bitpump data rate still Nx64+16 or is it just Nx64?, in other words, did my 384 kbps SDSL line (as billed) really operate at 384 kbps or 400 kbps at the bitpump level? For some reason these were the only two possibilities I thought of at the time, and I couldn't realise that the bitpump data rate could in fact be absolutely anything.

The true CM SDSL data rates were in fact published in some accessible documentation, though perhaps not as prominently as they could have been. However, I wasn't willing to believe the published numbers at one point! When I saw the numbers 160, 208, 320, 416, 784, 1040 and 1568 kbps, I kept thinking that it had to be some mistake on the part of the documentation writer. The numbers didn't fit any formula known to me, so I couldn't believe them.

While I understood on one level that the bitpump data rate could be anything, my rational mind kept looking for a reason why one set of numbers was chosen over others. Knowing what I know now, it appears that the reason was a chain of historical considerations, and that CM being a very early SDSL pioneer had a lot to do with it.

That there had to be some framing overhead to make up the difference between 384 and 416 kbps

I don't remember whether I still believed at that time that a 384 kbps CM SDSL line ran the bitpump at 400 kbps or if I had already accepted that it's actually 416 kbps, but given either of those numbers, I felt absolutely sure that there had to be some kind of framer on the quat stream combining 384 kbps of payload with 16 or 32 kbps of overhead. I believed it so much that I kept pondering what kind of framer was it that added either 16 or 32 kbps of overhead, given that some CM data rates appear to fit the Nx64+16 formula, whereas others fit Nx64+32.

When a Mindspeed support engineer had told me that CM used no framer and only used an HDLC-based protocol, I thought he was mistaken. When I had confirmed the same through reverse engineering of the CopperRocket hardware and firmware, I started thinking that perhaps there was a lot of padding added to the HDLC encapsulation so that the effective throughtput is reduced to something around 384 kbps even though the HDLC bit stream runs at 416 kbps as does the bitpump. In other words, I felt sure that there had to be something to bring the payload data rate down.

But the answer that has finally shocked me is that (as it appears from all available evidence) CM really did give out some extra bandwidth for free! If you ordered a 384 kbps SDSL line served from a CM DSLAM, you actually got 416 kbps of bandwidth while paying only for 384! There might of course be some higher-level mechanism that restricted it completely artificially by dropping packets, but that seems very doubtful. Everything indicates that CM really was nice enough to give out some extra free bandwidth!

One gets to truly appreciate CM and the lost beloved Rhythms Enterprise DSL network when one contrasts CM SDSL with the Nokia one. With the latter, when you buy a 384 kbps SDSL service, the bitpump does indeed run at 384 kbps, and there is a little bit of framing overhead beyond the ATM cell headers. In other words, when you buy 384 kbps from a CM DSLAM, you actually get a little more; when you buy 384 kbps from a Nokia DSLAM, you actually get a little less.

That the CopperRocket used bit-banging on the bitpump's channel unit interface

When I had disassembled and peeked inside my SDSL CopperRocket for the first time, I was still under my big misconception described earlier about the use of HDSL framing. I thus expected to find an 8973 bitpump with an 8953 HDSL framer inside SDSL CPE, and was quite surprised to see none of the latter. Opening my CopperRocket for the first time, I was surprised to see nothing more than a microprocessor, a lone bitpump (8970 rather than 8973) and an Ethernet chip.

The lack of an 8953 chip got me finally questioning the use of HDSL framing, and the bitpump being an 8970 rather than 8973 made me scratch my head wondering how was its clock generated for different data rates (the ICD2053 programmable frequency synthesiser is a tiny chip and easily overlooked), but my real embarrassment is elsewhere.

Since all I saw inside besides the 8970 bitpump was the microprocessor and the Ethernet chip, I obviously wondered what was the bitpump connected to, and this is where I need a brown paper bag over my face. The microprocessor is actually a 68LC302, but it's a small TQFP and the engraving on the chip is also pretty small and a little hard to read. The end result was that I had somehow managed to misread 68LC302 as some variation of 68030, and of course my resulting confusion had no bounds.

68030 being a generic microprocessor without any special telecom functions, I was obviously stumped as to how it could connect to a bitpump, and it got me thinking that the CopperRocket was bit-banging the bitpump's channel unit interface in the parallel slave mode or somesuch. (And still thinking that CM used a framer, I was thinking along the lines of a software framer implementing octet-oriented ATM or HDLC...) Such a design would of course be absurd, but at that point I was so bewildered by the zoo-like world of SDSL that I was ready to believe anything.

A closer look at the engraving on that microprocessor chip has put everything in its proper place. It's a 68LC302, not a 68030! 68LC302 is a telecom-oriented highly integrated processor (it's actually the low cost version of the classic 68302) and has a synchronous serial HDLC controller on-chip, which is indeed where the bitpump is connected. In other words, the hardware design I was looking at was in fact absolutely perfect for SDSL Flavor B. No framer, no bit-banging, none of the other lunacy I had dreamed up earlier.