This summary is not a substitute for reading CM's documentation (available on our FTP site), instead it should be used as a kind of study guide for helping one understand the material that is sometimes organized rather poorly in CM's docs.
Every interface (DSL port, WAN uplink virtual circuit, SCM Ethernet)
that is configured with NetModel=IP is attached to the DSLAM's
IP stack following classic IP routing rules.
There is only one IP stack per DSLAM, so the IP netmodel is global
in that sense.
A DSL port configured for the IP netmodel is logically treated like an Ethernet interface and a bridged MAC encapsulation is required. (See the encapsulations page.) This stipulation is arguably the greatest misfeature in the whole architecture. In contrast, a WAN uplink virtual circuit configured for the IP netmodel is treated as an unnumbered point-to-point link interface and is expected to carry a routed RFC 1483 or RFC 1490 encapsulation!
Configuring the Ethernet port on the System Control Module (PII 1.2.1) for the IP netmodel attaches the DSLAM's IP stack to a standard IP-carrying Ethernet network (netblock) at the CO site.
The VWAN netmodel implements Ethernet MAC bridging.
A DSL port configured for the VWAN netmodel is naturally required to
use a bridged MAC encapsulation, but there is some latitude in what it
gets bridged to and how.
Specifically, every DSL port configured for VWAN must be directed via the
DestPII setting either to a virtual circuit on a DS3 or similar
WAN port, or to the SCM Ethernet port (1.2.1).
A DS3 virtual circuit or SCM Ethernet port configured for the VWAN netmodel
and all DSL ports which have it as their DestPII form a VWAN
group.
Each VWAN group is independent and logically isolated from other VWAN groups
and from the rest of the DSLAM.
If a VWAN group consists of a DS3 or other WAN virtual circuit and a single DSL port, the result is straightforward MAC frame cross-connect, no MAC address-learning bridge functionality. It is effectively equivalent to the cross-connect netmodel except that only MAC-encapsulated packets are allowed and any two bridged MAC encapsulations may be cross-connected. This is the canonical way of serving CopperRocket subscribers from a DSLAM that otherwise uses the cross-connect netmodel exclusively.
MAC address-learning bridge functionality is brought into the picture when any DSL ports are bridged to the SCM Ethernet port (even just one DSL port) or when two or more DSL ports are bridged to a WAN virtual circuit.
It is possible to configure the SCM Ethernet port for VWAN, but still
keep its connection to the DSLAM's IP stack (either to use IP routing on
other interfaces or for configuration access).
To do that, set NetModel=VWAN in cmIfaceTable
on PII 1.2.1, but also configure the IpAddr and
NetMask objects.
The Ethernet port will then work just like in the IP netmodel, but will also
be available for use as the DestPII for DSL ports using VWAN.
(Presumably the Ethernet hardware interface is switched into promiscuous mode.)
This is a weird netmodel that is kind of like an IP-aware version of VWAN.
It is similar to VWAN in that one forms CopperVPN groups,
each group consisting of a WAN VC and one or more DSL ports which
have that WAN VC as their DestPII, and each group is
logically independent and isolated from the rest of the DSLAM.
Just like the VWAN netmodel and the misdesigned IP netmodel, the old
CopperVPN used bridged MAC encapsulations on the DSL side, i.e., it was
clearly designed for dumb CopperRocket users.
However, it presents routed IP on the WAN VC, and that is its main
difference from VWAN.
We defer to CM's documentation for lack of a better explanation.
The HDIA (High Density IP Access) netmodel has been eliminated in version 7.0 of the DSLAM software (the only version for which we have the complete manual set), so again we have a very incomplete understanding of it. The only manual in the Version 7.0 set that has retained any information about the HDIA netmodel is the one covering the CopperView GUI.
HDIA was apparently intended to serve the needs of those users who wanted
to have their hosts connected directly
to their DSL service
(without a router), but could not stomach the idea of V.35 (the proper way
to achieve the desired effect in the opinion of the hacker writing these pages),
using Ethernet-based kludges instead.
If a customer has one or more host computers with nothing but Ethernet interfaces and he wants to have them connected to the external public Internet without any kind of router CPE, the straightforward solution is to give him a bridged DSL circuit, take an IP netblock and assign it to the bridged Ethernet segment. (One can either use the IP netmodel on the DSLAM or have the Redback router or whatever do the equivalent.) The problem is the waste of IP addresses: a block of 4 addresses (/30 subnet) would be wasted on a customer with only one host computer! (In contrast, if that customer was willing to stick a V.35 card in his PC and get a routed SDSL circuit served with a CupreDSU, only one IP address would have been needed. But this idea is apparently considered blasphemous by everyone other than me.)
HDIA was designed to provide an alternative that is technically a kludge, but saves IP addresses. With HDIA the DSLAM is configured to serve a certain block of IP addresses to a DSL port using a bridged MAC encapsulation, but the way those addresses are served out is more akin to a routed circuit. The DSLAM does not take 3 addresses out of that block for reserved broadcast functions and for itself, instead every address in the block is made available to the user. Thus a user with a single PC only needs a single IP address (/32) and a /30 block can serve 4 host computers!
The trick is that the customer is then instructed to configure his Ethernet interfaces for a much larger netblock than what is actually assigned to his circuit, and a kludge in the DSLAM makes it work. Whenever one of the customer's hosts makes an ARP request for an IP address which it thinks is present on the local Ethernet, but in actuality belongs to someone else, the DSLAM makes a proxy ARP reply and forwards the IP packet to the other port. (One could achieve a similar effect by bridging unrelated customers together with VWAN, but then there would be no guard against one customer grabbing an IP address belonging to someone else, either by mistake or maliciously. HDIA does enforce separation by knowing which IP addresses belong to whom.)
Another noteworthy feature of HDIA is that in one very special case (which is practically unusable) it can serve out an internally-terminated (not cross-connected) true routed IP encapsulation on the SDSL side! See below about multiple VCs and voice IADs.
We've been unable to set up lab experiments with the HDIA netmodel on
our DSLAM running software version L3.0 because this netmodel seems to
work in a way similar to VWAN and CopperVPN: one must set up groups bonded
together by DestPII settings and a DS3 virtual circuit as
the group leader
, and each group is logically isolated from the
DSLAM's real IP stack and from everything else.
That in turn requires a working DS3 connection. :-(
The HDIA netmodel cannot be set on the Ethernet port PII.
The new CopperVPN netmodel in version 7.0 is intended to replace
both the old CopperVPN and HDIA.
Again it is group-based: one designates an uplink interface as the
group leader
and adds DSL ports as members of that group by setting
their DestPII objects to the PII of the leader
port;
each group is logically isolated from other groups and from the rest
of the DSLAM.
CM's documentation calls CopperVPN groups transparent virtual routers
.
The DSLAM maintains what they call an Address Translation/Forward table
that lists which IP address belongs to which DSL port in the group; this
table may be either configured manually or auto-learned in various funky ways.
I find this netmodel rather counter-intuitive and admit to not really
understanding it;
interested readers are welcome to peruse CM's documentation.
The most noteworthy feature of CopperVPN Version 7.0 in the opinion of the hacker writing these pages is that it explicitly offers the choice of either MAC or IP encapsulation on both the WAN side and the DSL side. Furthermore, it allows the SCM Ethernet port to be used as the uplink, albeit at the price of making it unusable for configuration, so at least in theory it may allow one to serve out a true routed DSL circuit in the absence of DS3 backhaul.
We have recently obtained and installed CE200 software version 8.0 which has this new CopperVPN netmodel, but because we've already concluded that it's screwy, the motivation to experiment with it just isn't there.
This is the simplest netmodel because it punts all real work to some
undefined other
box on the other end of an ATM or FR WAN PVC.
See this page for more information.
The cross-connect netmodel naturally requires a DS3 or similar WAN
interface, not Ethernet.
One blemish of CM's architectural design is the asymmetric treatment
given to WAN and DSL ports when it comes to having multiple virtual circuits
per port.
Given that (for example) a DS3 Frame Relay WAN card and an SDSL port are
both HDLC bit streams in the fundamental sense, they ought to be treated
as having equal rights
, but that is not the way the DSLAM works.
When one configures the netmodel and its related settings on the WAN side,
that configuration is done at the virtual circuit level.
Each WAN side PVC has its own cmIfaceTable entry, and there is
no entry for the DS3 physical interface as a whole.
That makes perfect logical sense — the logical operation of the physical
DS3 port is fixed and unambiguous: it distinguishes between different VCs
based on Q.922 addresses for FR or VPI/VCI for ATM, and presents each VC to
the software as a separate entity for further processing.
All further configuration is then done at the VC level.
But the situation is markedly different for DSL ports: each DSL port has
a cmIfaceTable entry as an interface entity in itself, and
the available support for multiple VCs on a single DSL port leaves something
to be desired.
CM's original design apparently allowed multiple VCs per DSL port only
in the cross-connect netmodel.
With all other netmodels only one logical circuit/interface exists, and the
available encapsulation types imply the DLCI number.
(Specifically, EncapsulationType=rfc1490 implies DLCI 16
whereas EncapsulationType=rfc1483 implies DLCI 528.
See this page for more information
about encapsulations.)
With the cross-connect netmodel one uses cmSubIfaceTable
to specify the WAN VC PII to which each DLCI on the DSL side should be
cross-connected, but the encapsulation is controlled very indirectly.
EncapsulationType settings such as rfc1483 and
rfc1490 are not valid for the cross-connect netmodel at all,
instead the only valid settings are Q922, Q922-1490
and rfc1973.
The encapsulation on each DSL VC is then deduced indirectly from the
DSL port level encapsulation and the encapsulation configured on the
cross-connected WAN VC!
Apparently CM's poor design came back to bite them in the ass when they needed to support pre-standard VoIP IADs. These beasties needed a separate virtual circuit over SDSL to carry IP-encapsulated voice traffic of the pre-standard-VoIP variety, and supporting that operation properly required the use of two different netmodels for the data VC and the voice VC. Oops, CM's design didn't support that!
CM has implemented a kludge to solve their specific IAD problem in a
very ad hoc manner.
DLCI 22 on SDSL outputs is special in that it may be configured
in two ways.
One can configure it with cmSubIfaceTable in the cross-connect
netmodel, in which case nothing special happens,
or one can create a cmIfaceTable entry for it, which would
have its own NetModel, EncapsulationType and
DestPII fields.
The DLCI 22 hack is not a general purpose solution
though,
as the DSLAM imposes very tight restrictions on what you can do with that
cmIfaceTable entry.
Specifically, this cmIfaceTable entry allows only two netmodels:
cross-connect and HDIA.
Setting the cross-connect netmodel on VC 22 is practically equivalent
to the standard cmSubIfaceTable mechanism except that the
VC 22 method may be used even if the primary netmodel is something
other than cross-connect.
OTOH, the HDIA netmodel on VC 22 behaves specially:
In version 7.0 HDIA has been replaced with the new CopperVPN netmodel, but we have every reason to expect that it's just as screwy.