How it works

The good old Frame Relay Forum has produced a spec called FRF.16 (Multilink Frame Relay UNI/NNI Implementation Agreement) that provides just the right functionality and even uses the same terminology as CM.

It would have been great if CM's IMUX functionality were nothing more than an implementation of FRF.16, but unfortunately we aren't that lucky. By sniffing the bit streams off the Netopia wanlet (see the booty here), we have determined that CM's IMUX is actually a non-standard or bastardized variant of FRF.16. The packet format used to carry payload data over bundle links does agree with the FRF.16 spec, but the bundle membership check protocol is totally different.

The FRF.16 spec prescribes a Link Integrity Protocol by way of which each endpoint identifies itself to the other end, all links making up the bundle are matched up and the health of each link is monitored separately so that if a link goes down, all traffic is automatically redirected to the remaining link(s). CM IMUX has all the same functions, but unfortunately they are not done via FRF.16 LIP; instead they are done via CMCP. This design makes CMCP a prerequisite for IMUX unfortunately.

If one tries to create a DML bundle from SDSL member ports that are configured with CMCPCompatible=No, the configuration appears successful at first, but as soon as the physical layer comes up the DSLAM immediately throws up a CPE in bundle is not IMUX capable error. Instead DML bundles must be made up of member ports left at the default setting of CMCPCompatible=Yes, and any CPE hoping to connect to such loops needs to be able to talk CMCP before it can get anywhere further.

Anyone who is interested in making an open source router connect to Copper Mountain DML would need to either do the legwork of reverse-engineering CMCP or fund Harhan's work to do the same — but see below about the MLPPP alternative.

Another item in need of clarification is the maximum number of lines that can be bonded. There is room in cmBundleTable for 4 member port PIIs, but the DSLAM manuals we have for Version 7.0 claim that only 2-member bundles are supported. It appears that Netopia had made IDSL IMUX CPE (see below) that supported 4 lines, so I imagine it must have worked on the DSLAM side at least at one time, but of course it would need to be tested — but it can't be tested until we have our own implementation that is able to link up with at least one loop out of a DML bundle!

Existing IMUX CPE

Very few SDSL/IDSL CPE models with IMUX support (i.e., with more than one copper loop interface circuit in hardware) have been made to our knowledge. Here is the complete list of all models we know about:

Netopia R7171/D7171

This is the canonical SDSL IMUX CPE device, supports 2 lines. Very limited availability on the surplus market and Netopia's defective-by-design firmware gets in the way of anyone trying to put one together themselves: see this page for more information.

Netopia D3232

This is Netopia's pseudo-DSU CPE device for IDSL IMUX. It is the only IMUX CPE device ever made to our knowledge that supported 4 lines. There probably was an R3232 router version too.

CopperRocket 202

This is CM's own SDSL IMUX CPE device. It appears to be even rarer than Netopia's 7171, i.e., total vaporware. I haven't even been able to find a picture of one with Google image search, all that could be found for it were CM's old press releases.

The most amazing thing about this CPE model is that according to those press releases, it was not an Ethernet bridge like the regular CopperRocket 201 nor a router, instead it was a pseudo-DSU with synchronous serial hand-off! CM's DSLAM documentation instructs operators to configure the standard RFC 1490 encapsulation instead of CM 1483 on DML PIIs going to CR202 CPE, so the intent is obviously not for the CR202 to terminate it, but for it to go to the customer's own standards-based router. Hooray! (Read this blurb about how such IMUX pseudo-DSUs work.)

My first guess was that CR202 was probably a rebadged D7171 from Netopia (kind of like the M7100 situation in reverse), but that doesn't seem to be the case after all. There is no way to tell for sure without a picture or an actual unit, but there is a blurb in CM's DSLAM documentation that gives the downloadable firmware image filenames for different CPE models, and judging from that CR202 appears to be more similar to CM's IAD CPE, not Netopia. Also CM's documentation of CMCP management functions which can supposedly be done on a CR202 doesn't match the CMCP behavior of Netopia's CM SDSL wanlets on a 7171.

CopperRocket 212

This is CM's own IDSL IMUX CPE device, same vaporware situation as with CR202.

According to CM's old press releases, CR212 was not a pseudo-DSU like CR202, instead it was an Ethernet bridge like the regular CR201. It also apparently supported only 2 lines, not 4 like Netopia's version.

MLPPP alternative

After having taken a long and hard look at CM's IMUX functionality, we are starting to have doubts as to whether it would really be worth all that effort to reverse-engineer CM's DML protocol and to make an open source implementation thereof given the alternative of bonding with MLPPP. The DML route (bonding in the DSLAM) has two big hurdles associated with it:

We would first need to reverse-engineer CMCP before any open source implementation can connect to DML bundle loops, and that may involve considerable work.
Suppose we've got CMCP cracked and we have a proof of concept implementation linking up with the DSLAM on 2 or more loops making up a DML bundle. How would we turn it into a usable product? Because CMCP and CM's bastardized version of FRF.16 are so non-standard, one would never be able to support them with a standard off-the-shelf router like Cisco. Instead we would need to build our own modular router platform and carry that massive project from start to finish before we can have a usable product, just so we can hack in the special support for CMCP and pseudo-FRF.16.

Now consider the MLPPP alternative. If you are able to operate your DSLAM in the cross-connect netmodel instead of the IP netmodel (DS3 or similar uplink instead of Ethernet, see this page for the explanation), you can do the bonding on the Cisco/Redback/whatever router in front of the DSLAM rather than in the DSLAM itself, and then you can use industry standard bonding methods like MLPPP or end-to-end multilink Frame Relay (FRF.15). The DSLAM would then be blissfully unaware of the bonding; it would simply cross-connect each loop in the bundle to a separate ATM or FR PVC on the DS3 interface.

No bonding in the DSLAM means no need for CMCP (set CMCPCompatible=No), and the CPE problem becomes trivial: just take N XSB-2000 DSUs (SDSL to V.35 units compatible with the Copper Mountain flavor sans CMCP) and a standard Cisco router (very cheap on the surplus market) with N synchronous serial ports, and voila — you've got a bonded SDSL CPE device for N loops, supporting standard MLPPP.

The only limitation with this approach is that it requires that you stick another box in front of the DSLAM to do the routing; you wouldn't be able to use the DSLAM itself as the router. Going the DML route would allow one to use the DSLAM as the router (IP netmodel). However, as much as we would love to have someone fund our HECGW project, our ethical philosophy also requires us to tell you honestly that it would probably cost you less to buy a good off-the-shelf Ethernet-to-DS3 router, stick it in front of your DSLAM and live happily everafter with open standards-based MLPPP bonding and modular CPE using standard Cisco routers and DSUs.

Oh, and one other advantage of doing the bonding in another box in front of the DSLAM is that this way there is no limit on the number of loops that can be bonded.