The good old D7100

Some of Netopia's products based on their generic router platform consisting of the UMB3 motherboard and WAN modules were not routers! In the golden days of Copper Mountain Netopia had made a product called SDSL CSU/DSU, model number D7100, as well as IDSL and IMUX versions discussed below.

Although at the time I had very much longed for a true DSU first for IDSL, then for CM SDSL, I had a difficult time accepting Netopia's solution as being what I wanted. In actuality it is quite a stretch to call the product in question a CSU/DSU. Even though the manual calls it such on the front page, reading further reveals that the device can actually function in two modes: either a DSU for Frame Relay (all documentation keeps saying FR explicitly, even though a DSU is supposed to be protocol- and encapsulation-transparent) or an Ethernet bridge (a filtering bridge to use Netopia's exact words).

If that wasn't enough, additional turn-offs are:

• There is no user configuration to select between the different-as-night-and-day DSU and Ethernet bridge modes, instead the box tries to read the user's mind telepathically it seems.

• In both modes the unit still has Ethernet, wants an IP address and is thus obviously IP-aware. In the DSU mode the IP-aware Ethernet port is supposedly only for O&M and isolated from the data path, but how is that isolation worth anything if there is no way to guarantee that the unit will stay in the DSU mode and won't switch to the bridge mode based on its psychic sense? (As for the bridge mode, isn't it rather self-contradictory for a bridge to have an IP address of its own? I suppose it can be viewed as a bridge and a node connected together without giving the user an option to separate them.)

Now that I know that Netopia had no separate CSU/DSU hardware and that a D7100 is identical to an R7100 router in terms of hardware, things fall into place a little better. However, some choices made by Netopia still defy reason:

• If the hardware is identical anyway, why didn't they support all three modes of operation (router, bridge, DSU) in one product? They could have made the bit stream from the WAN module explicitly switchable between the router's processor and the auxiliary port, and if it was switched to the processor, the firmware could then implement routing or bridging per further configuration options.

• If there was some compelling reason to make two separate products, it would have surely made more sense to combine the router and DSU modes in one and put the bridge mode in the other. Given that routed and bridged DSL circuits are different in terms of how an ISP configures them, it would have been quite natural to have one product (router/DSU) handle routed circuits and have the other handle bridged ones like the CopperRocket.

If you are looking for a true DSU for SDSL, check out our OSDCU or the XSB-2000.

D3100 for IDSL

The single-line IDSL counterpart to D7100 is D3100, but the following aspects are unclear:

• Is it for CM IDSL only, or does it support other flavors?
• If support for non-CM IDSL is present, how did it evolve over time?
• If support for non-CM IDSL is present, how does it auto-decide between the DSU and bridged modes? The logic used by D7100 seems awfully CM-centric.

IMUX pseudo-DSUs

The relic documentation we've been able to find mentions two other members of the D-series DSU product family: D7171 and D3232. These are the D-series versions of Netopia's IMUX CPE. They are definitely CM-specific. D7171 bonds 2 SDSL lines and D3232 bonds 4 IDSL lines; we don't know if there ever was a D3131 or D3200 for 2 IDSL lines. (Remember, you can't just put together whatever configuration you like, Netopia's defective-by-design firmware will reject anything that wasn't expressly blessed by them.)

The existence of IMUX versions proves that D-series products are not true bit-transparent DSUs, but rather pseudo-DSUs: the DCE port is synthetic (it's really a DTE, but a clock is also synthesized to approximate the DSL link bandwidth) and the CPU forwards packets between this auxiliary port and the DSL link (single or IMUX); the DCE port is not connected directly to the SDSL bitpump as in a true DSU.

It is clear that CM and Netopia had a different view than I do on how the concept of a DSU should apply to inverse multiplexing. The approach I plan on taking will use completely bit-transparent dumb DSUs, one per line, and they will be connected to a router that implements FRF.16 (the IMUX protocol). But CM and Netopia took the opposite approach where the IMUX bonding is done in the pseudo-DSU and the synchronous serial bit stream going to the router is synthetic, keeping the router blissfully unaware of FRF.16.