Although our project is mostly concerned with enabling end users to connect to their SDSL circuits using exclusively open source means, i.e., we are not concerned as much with how ISPs run their business on their end, in the case of Copper Mountain it is necessary to understand a little bit about the capabilities of the DSLAM as seen by an ISP in order to fully understand what comes out on the subscriber's side of the line.
Unlike most other DSLAM brands (such as Covad's Nokia D50 or Lucent Stinger), CM DSLAMs can operate in two different fundamental modes:
In what CM calls the IP netmodel, the DSLAM acts as an IP router. A DSL port configured for the IP netmodel is presented as an interface to the DSLAM's built-in IP stack on equal with its other interfaces (Ethernet or DS3 uplink); standard IP rules apply from there onward.
In what CM calls the cross-connect netmodel, a DSL port is logically cross-connected at OSI Layer 2 to a virtual circuit on the DSLAM's uplink interface. The latter is DS3/ATM on most DSLAMs that show up on the surplus market; other WAN module types are much rarer. The Ethernet port may not be used as the uplink in the cross-connect netmodel.
For the sake of completeness, CM supports several other netmodels which
you can read about in their documentation (available on our
FTP site);
we have also put together a summary
on this page.
Those other
netmodels are
of very limited practical usefulness in the opinion of the hacker
writing these pages, hence our focus will be on the IP and cross-connect
netmodels.
The cross-connect netmodel worked very well for CLECs like Rhythms and
Northpoint.
These CLECs stayed out of the IP-based ISP business and instead provided
Layer 2 transport to their partner ISPs.
They operated ATM networks with DS3 feeds into each DSLAM-equipped CO and
ATM switches at higher-level aggregation points, and an ATM interface with
gazillion virtual circuits (one per subscriber) was presented to each
partner ISP.
The ISPs in turn operated very smart MegaPOP
routers from
Redback Networks or equivalent which connected to the ISP's IP backbone
on the input
side and put out an ATM PVC per subscriber on the
output
side.
However, a small independent ISP that needs to go directly from their
pool of bandwidth and IP address space on the input
to subscriber
loops on the output
without going through a Layer 2 aggregation
network in the middle would find CM's IP netmodel much more convenient.
Such an ISP needs to have some box that takes the available pool of
bandwidth and IP address space and doles it out to subscribers, and a CM DSLAM
running in the IP netmodel can act as that box.
If the ISP had to use a DSLAM that does Layer 2 cross-connect instead
(either CM or another brand), they would have to have an extra box sitting
between the DSLAM and their IP network, a box similar to the Redback routers
used by the larger ISPs who go through Layer 2 aggregation networks.
Needless to say, no ISP would want to use an extra box if they can avoid it.
A box of that kind is likely to be quite expensive, it would need to be managed
and maintained, there would certainly be issues and peculiarities to deal with,
provisioning would cumbersome,
and the DS3 pigtail
interface between the DSLAM and the extra box
would be completely artificial and otherwise unnecessary.
Hence our assumption that a small independent ISP with a Copper Mountain DSLAM
would almost certainly operate it in the IP netmodel.
A very major shortcoming of the CopperEdge DSLAM (which is otherwise a fairly capable design) is that all DSL circuits served out with the IP netmodel must be bridged, not routed — translated into plain English, the CopperEdge is too dumb to serve out a routed DSL circuit with the IP netmodel. (See this page to review the difference between routed and bridged DSL circuits.) Routed DSL circuits can only be served out with the cross-connect netmodel.
For the sake of completeness, the weird HDIA netmodel in the older DSLAM
software versions does support serving out a routed encapsulation
(EncapsulationType=ip-1490) in the very special case of
voice VC 22
, but this feature is not practically usable except
for the special IAD application it was created for.
Its CopperVPN replacement in the newer versions appears to support serving out
routed encapsulations in a slightly more general case, but it still seems to
be far too specialized and inflexible to be practically useful.
See our netmodels page for the full explanation.
The result of all of the above is that small independent ISPs with CM DSLAMs are probably able to serve out bridged circuits only, not routed. In order to serve out routed DSL circuits, such an ISP would need to use an extra box that enables the cross-connect netmodel to be used (or use a hack like we did), and that can only happen if the ISP is very determined to serve out such circuits for ideological reasons, something that can't be expected of commercial operations.