We have implemented a rudimentary IP router application on our Hack-o-Rocket platform, and we have used it to prove successful 100% open source connectivity to Covad SDSL and IDSL circuits cross-connected to 3rd-party ISPs (not Covad IP).

The HoR IP router is extremely primitive and bare-boned; it comes nowhere close to complying with RFC 1009. However, at the present time it is the only router in the world to the author's knowledge which makes a 100% open source connection to SDSL. The router code exists in 3 versions:

The only encapsulation supported on the line is straight routed, i.e., routed RFC 1490 for IDSL and Flavor B or routed RFC 1483 for Nokia SDSL/ATM. No support for bridging, MER or PPP on the line. (Please read this page for a good explanation of the difference between routed and bridged circuits.)

Performance

The IDSL and SDSL Flavor B versions of the HoR IP router use the CR201 hardware pretty much in the way it was meant to be used: the MC68LC302 SCC speaks HDLC and does a very good job at it, the CS8900 Ethernet chip sends and receives packets on the LAN interface, and the code running on the CPU routes IP datagrams between the two interfaces just like a traditional gateway design. The only differences from CM's original CopperRocket are that we do IP routing instead of bridging, don't speak CMCP and have a very Spartan configuration mechanism. We have no good way to test it, but we expect the Flavor B version to perform well at all SDSL data rates all the way up to 1568 kbps just like the original CopperRocket.

On the other hand, the Nokia SDSL/ATM version is an example of thinking outside the box. We use the MC68LC302 SCC to receive and transmit 432 octet long Nokia frames and implement the higher ATM and AAL5 layers in pure software. Amazingly, it works, but there are significant performance limitations. Here is how we perform at different Nokia SDSL data rates:

192 kbps
Works well with the line saturated in both directions.
384 kbps
Handles a fully saturated downstream pipe, but is able to fill only a portion of the line bandwidth in the upstream direction (transmits a lot of idle cells/frames). An upstream FTP transfer test clocked in at about 26 kbyte/s.
768 kbps
Same story as at 384 kbps, but the effective upstream bandwidth as measured by FTP transfers is even less (about 24 kbyte/s) due to the greater interrupt load and saturating the pipe in both directions with two FTP transfers at the same time causes occasional recoverable underruns (shutdowns followed by restart).
1152 kbps
1536 kbps
Unusable — the slightest bit of downstream traffic causes an immediate underrun. The link gets re-established, but as soon as TCP retries sending, another underrun immediately occurs.

The executive summary is that the Nokia SDSL router works well at 192 kbps, OK at 384 kbps if one is willing to live with a reduced effective upstream bandwidth, risky and not recommended at 768 kbps, unusable above that.

The Hack-o-Rocket IP router is viable as real operational CPE if one fits within the limitations of performance, encapsulation support and O&M capabilities, and Harhan does in fact use one as the operational CPE on our Verizon Business 384 kbps SDSL pipe, but given all of its limitations, the Hack-o-Rocket cannot be seriously marketed as a real end user product.

How can I get one?

The HoR IP router is part of the Hack-o-Rocket software kit. See our main page for information on how you can make a Hack-o-Rocket unit or get one made for you.

Going forward

The Hack-o-Rocket was a proof-of-concept implementation. Our next subproject within the Open SDSL Connectivity Project is the OSDCU. It will definitely be more expensive than getting an old CopperRocket from eBay and making a Hack-o-Rocket out of it, but the difference in hardware performance, software modularity and the overall product quality resulting from the previous two will also be quite significant. As they say, you get what you pay for.

After we finish building the OSDCU for SDSL/2B1Q, we'll think about what we should do for IDSL.