SDSL stands for Symmetric Digital Subscriber Line. It is an Internet connection technology that fills the gap between cheap consumer Internet services and high-end services like T1 and Frame Relay. SDSL is the ideal Internet connectivity option for low-budget non-profit organisations that run their own servers. The challenge this group of users faces is that for running servers one needs something more dedicated and business-oriented than a consumer Internet service like ADSL or cable, yet traditional dedicated services like T1 and Frame Relay are still too expensive for a low-budget non-profit organisation.
SDSL is the solution. It's a symmetric fixed bit rate service that runs over a dedicated pair of wires (unlike ADSL which requires sharing a pair with a residential phone line, an insult to any self-respecting server operator), offers bandwidth options in the same range as fractional T1 and Frame Relay, but is only slightly more expensive than consumer DSL.
NOTE: our project has originally started with SDSL/2B1Q, but has now been expanded to include G.shdsl and IDSL as well.
SDSL suffers from one serious problem, and solving this problem is the
primary purpose of our project.
The problem is that of Ethernet handoff
.
While the same companies that make crappy consumer DSL routers also make T1 models, with a T1 you have the option of NOT using one of those crappy consumer-grade routers. You can instead get a T1 CSU/DSU from Adtran, ADC/Kentrox or a host of other vendors that will terminate the T1 at OSI Layer 1 and present an industry standard V.35 interface which you then connect to the router of your choice. In other words, with a T1 you can opt for V.35 handoff instead of Ethernet handoff.
If the powers that be (ISPs) were to offer fractional T1 services of say, ¼ of the full T1 bandwidth (384 kbps) for ¼ of the full T1 price, that's what we would use and all our problems would be solved. But they don't: the price of a fractional T1 is almost the same as that of a full T1, and sometimes even higher!
Those of us who don't need full T1 bandwidth and don't want to pay T1 prices are thus stuck with SDSL as our only option, and SDSL suffers from one fatal flaw compared to T1: there is no V.35 handoff option for SDSL like there is for T1.
There is no V.35 handoff option for SDSL because no one makes SDSL-to-V.35 DSUs, and the reasons for that are multifold:
The end result is that when you get an SDSL line, the only way to connect
to it is to use the closed black box
router provided by the ISP,
and those routers are very horrible.
Bridging may sometimes be a possible workaround,
but there is a host of other problems associated with that too.
Side note: Although it's outside the scope of this project, ADSL suffers from exactly the same problem. The only difference is that the repertoire of available CPE choices is wider for ADSL and thus the user has a higher chance of finding something tolerable. But the fundamental underlying problem is exactly the same.
The solution is to design and build our own SDSL CPE that is qualitatively
different from the crappy routers which comprise
the current repertoire of choices available to an SDSL user.
But what should this qualitatively different
CPE be like?
The answer is very subjective: your idea of the perfect SDSL CPE device may be
very different from mine simply because we have different requirements, not to
mention different tastes.
The hacker leading this project believes that the problem and the solution to it should be divided into two parts:
To forcibly recover the specifications for the proprietary SDSL flavors and to prove the possibility of a totally open source connection to an SDSL circuit with a working proof-of-concept implementation. The proof-of-concept open source CPE in this stage doesn't need to be pretty, user-friendly or optimal for any particular application, it just needs to prove the possibility of connecting to the line directly without using the conventional proprietary CPE. This is a freedom-fighting and reverse engineering problem.
Once open source connectivity to a particular SDSL flavor or set of flavors has been achieved and the open source community possesses a set of specifications which has been proven to be correct and complete (or at least sufficient for implementation), other engineers can design different open source CPE products for different application requirements and tastes. This is a conventional engineering problem, not political any more.
We have now successfully completed part 1 for several flavors of SDSL/2B1Q and for Covad IDSL, and we have managed to do so without building any hardware of our own. Instead we have written our own hack-firmware suite for the old CopperRocket hardware platform, turning it into a Hack-o-Rocket, and we have used the latter to reverse-engineer several SDSL flavors, culminating in the Hack-o-Rocket router making a successful 100% open source connection to Covad IDSL and SDSL.
The Hack-o-Rocket is a functional SDSL/IDSL router and can be used as real operational CPE on live circuits. However, it is extremely primitive, has serious performance limitations and is absolutely not user-friendly, hence we make no attempt to market it as a serious CPE router product for end users.
Instead we now enter stage 2 of the project in which we build upon our cracking and reverse engineering successes to build real SDSL CPE products of interest to us. Due to our peculiar technical taste, what we are most interested in building is not a soapbox router like the Hack-o-Rocket or the existing SDSL products, but a V.35-style DSU first for SDSL/2B1Q and then maybe for IDSL. The OSDCU will be our DSU for SDSL/2B1Q; there is also a possibility that we will provide a piggy-backed router option for it as well. Stay tuned!
It also goes without saying that if anyone else desires to build something SDSL-related that we have no plans of building ourselves, we would be more than eager to help with advice and insight. We already contribute a lot by putting more detailed technical information about SDSL on these web pages and our FTP site than any sane person would care to know.
There is a mailing list for this project.
To subscribe, send a message consisting of just the word subscribe
to
opensdsl-request@ifctfvax.Harhan.ORG.