What is CMCP

CMCP apparently stands for Copper Mountain Control Protocol, and it's a proprietary line and CPE management protocol implemented on the SDSL or IDSL line alongside with the regular encapsulation, supported in all netmodels. It's an in-band HDLC protocol. (Text strings inside CM's CPE firmware reveal that CMCP was originally called ICP, it seems.)

CMCP supports the following functions:

CMCP may be enabled or disabled per line using the CMCPCompatible object in cmIfaceTable.

Line bring-up with CMCP enabled

When the SDSL or IDSL physical layer first comes up on a line configured with CMCP enabled, the DSLAM starts sending an endless stream of CMCP packets that look like this:

Rx frame, length=54, flags: L F
0000:  84 00 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 01 02 01  02 00 80 01  00 0B 01 5F
0030:  DA EC 00 00  58 7F

Rx frame, length=54, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 01 02 01  02 00 80 01  00 0B 01 5F
0030:  DA EC 00 00  E4 7A

These packets are exactly the same regardless of the netmodel used on the line and regardless of whether the line is single or part of an IMUX bundle — see below. (See the CM 1483 encapsulation page for more information about the general format of these packets. In particular, read this section to understand why the packet is sent twice with the only change being the least significant bit of the second octet.)

Until the CPE sends a CMCP response, the link is not declared to be up to the rest of the DSLAM and no other kind of packets are allowed to go out on the line. We have performed an experiment in which we have linked up with some existing CM CPE devices (emulating a DSLAM), sent the CMCP packet shown above and captured the CPE response. Here is what we've got:

CR201s:

Rx frame, length=88, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF 00 60  58 01 5B C3  00 3C AA AA  03 00 60 58
0020:  80 01 02 01  02 00 03 01  06 00 80 01  01 0B 01 5F
0030:  DA EC 00 00  00 22 00 01  00 60 58 01  5B C3 00 60
0040:  58 01 5B C3  00 0A 00 00  00 00 00 00  00 00 00 00
0050:  00 00 00 00  00 00 43 08

R7100:

Rx frame, length=88, flags: L F
0000:  84 00 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF 00 00  00 00 00 00  00 3C AA AA  03 00 60 58
0020:  80 01 02 01  02 00 03 01  06 00 80 01  01 0B 01 5F
0030:  DA EC 00 00  00 22 00 01  00 00 C5 86  5B 06 00 00
0040:  00 00 00 00  00 10 00 00  00 00 00 00  00 00 00 00
0050:  00 00 00 00  00 00 3D 5A

R7171:

Rx frame, length=88, flags: L F
0000:  84 00 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF 00 00  00 00 00 00  00 3C AA AA  03 00 60 58
0020:  80 01 02 01  02 00 03 01  06 00 80 01  01 0B 01 5F
0030:  DA EC 00 00  00 22 00 05  00 00 C5 7F  64 0E 00 00
0040:  00 00 00 00  00 10 00 00  C5 7F 64 0E  00 00 00 00
0050:  00 00 00 00  00 00 0D DA

We then wrote a test program on the Hack-o-Rocket that looks for the DSLAM's initial CMCP packet and sends an R7171-emulating response. Here is the log of what we've got:

CMCP response is enabled
Rx frame, length=54, flags: L F
0000:  84 00 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 04 02 01  02 00 80 01  00 0B 0F FE
0030:  8A 74 00 00  44 5D

Rx frame, length=54, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 04 02 01  02 00 80 01  00 0B 0F FE
0030:  8A 74 00 00  F8 58

Detected CMCP initial query, sending response
Sent response packet:
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF 00 00  00 00 00 00  00 3C AA AA  03 00 60 58
0020:  80 01 02 01  02 00 03 01  06 00 80 01  01 0B 0F FE
0030:  8A 74 00 00  00 22 00 05  00 60 58 01  57 3D 00 00
0040:  00 00 00 00  00 10 00 60  58 01 57 3D  00 00 00 00
0050:  00 00 00 00  00 00

Rx frame, length=60, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 20 AA AA  03 00 60 58
0020:  80 01 06 01  06 04 02 01  02 00 80 01  00 0E 00 00
0030:  00 00 00 00  00 60 58 01  57 3D B5 23

Rx frame, length=54, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 04 02 01  02 00 80 01  00 0B 0F FE
0030:  8A 74 00 00  F8 58

[then the last two packets repeat ad nauseum]

As one can see, this ping-pong method of linking up alternately with the DSLAM and with a CPE device and sending each party an imitation of a packet captured from the other wasn't taking us very far, so took the next step. We have made a 2"x2" PCB with a 74HCT04 inverting buffer and a 26LS31 EIA-422 driver on it, and attached it to a Netopia/CM wanlet. We have sniffed the BCLK, RDAT and TDAT signals off the Bt8970 bitpump on the wanlet and fed them to our hack PCB with little wires; the output from this sniffer setup is a pair of EIA-422 bit streams: DSLAM to CPE and CPE to DSLAM.

We were originally planning on feeding these two sniffed bit streams to a DSV11 card on a MicroVAX (it's a two-port synchronous serial interface controller, so we were planning on capturing both bit streams simultaneously to see the full bidirectional packet exchange), but unfortunately our DSV11 card turned out to be dead. Lacking the schematics to troubleshoot and repair it and lacking the money to buy a replacement from a DEC surplus dealer (probably around $200 USD), we have temporarily settled for a kludge whereby we listened to only one bit stream at a time using the SCC2 connection on our OSDCU as an HDLC receiver.

The captured booty can be seen here. Having the DSLAM to CPE and CPE to DSLAM packet streams captured separately really hinders the reverse engineering of the protocol though, so if anyone seriously wants to do it, the first step should be to provide us with the funds to buy a replacement DSV11 card so we can get a capture that shows both packet streams (in both directions) with timestamps.

Line behaviour with CMCP disabled

When a port is configured with CMCPCompatible=No, the particular kind of initial CMCP packets shown above are not seen and the DSLAM declares the link to be logically up as soon as the physical layer comes up, but some CMCP packets are still transmitted occasionally.

The DSLAM does honor the no CMCP setting in that CMCP support does not seem to be required from the CPE in this mode, and whatever CMCP packets still do get sent out for some reason can be simply ignored. If the line in question is configured as a bridged circuit with the IP netmodel (see this page for the explanation of why this configuration was the easiest to test in the lab), pinging IP addresses assigned to the circuit results in ARP queries being sent in the RFC 1490 or CM 1483 encapsulation as configured.

A more serious issue exists with the keepalive mechanism. All of our experiments in this series were done by connecting a Hack-o-Rocket to the DSLAM and running code on the former that brings up the SDSL physical layer and dumps all received HDLC frames, but doesn't send anything back. In all of these experiments the DSLAM would shut the line off and retrain after a certain while: apparently it was getting concerned about seeing nothing whatsoever coming from the line and deciding to retrain the physical layer as a result. CMCP packets like the following were seen prior to that, seeming to be some kind of status or keepalive packets:

Rx frame, length=89, flags: L F
0000:  84 01 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 3D AA AA  03 00 60 58
0020:  80 01 06 01  06 01 01 01  02 00 80 01  00 02 00 04
0030:  0D 34 00 0E  FF FF 01 40  01 02 01 00  0B 01 00 04
0040:  41 EC 5F 90  01 0F 00 13  01 02 03 08  09 0A 0B 0D
0050:  0E 0F 10 11  12 14 15 F8  E2

We thus saw two possibilities:

  1. The CPE must periodically send some CMCP or LMI or other special packets in order the keep the link up indefinitely.
  2. As long as the CPE sends something on the line and not completely idle, the DSLAM will be happy — no special protocol or packet type.

In order to determine which is the case, we needed to connect a test line to something that didn't implement CMCP or LMI, but implemented the normal RFC 1490 payload encapsulation in both directions, i.e., not only received, but sent something meaningful too.

At first we had a difficulty with that because we couldn't serve out a routed SDSL circuit and we didn't want to expend the effort to implement bridging on the Hack-o-Rocket either. However, we have figured out a hacky way to serve out routed SDSL circuits using a quad T1 WAN module (described here), and we were then able to connect to such a circuit using our Hack-o-Rocket IP router.

The result of the experiment is that no special protocol or packet type is necessary: as long as the CPE sends something (e.g., ICMP pings) and the line never gets completely idle, the DSLAM's keepalive mechanism remains happy. We could keep pinging the Hack-o-Rocket's IP address and the link would stay up indefinitely, but if we stopped pinging and the line went idle, the DSLAM would shut off and retrain.

In a real operational setting (such as a routed CM SDSL circuit with our OSDCU connected to an open source router as the CPE) the sensible thing to do is probably to implement Frame Relay LMI on the router: CM seems to have good support for it and the periodic LMI polling packets would provide the necessary filler to keep the line from going completely idle.

It also needs to be noted that the XSB-2000 is a totally bit-transparent DSU and hence does not implement CMCP, yet it had received CM's official stamp of approval in its Larscom incarnation. Using a totally bit-transparent DSU with a Cisco router that implements Frame Relay LMI but no CMCP appears to be a totally legitimate option for routed circuits served via the Copper Mountain platform.

CPE management with CMCP

CMCP allows CPE devices to be managed remotely from the DSLAM side, but this capability is rather overrated as we have found out after reading CM's manuals. To get an idea of what can be done to the CPE from the DSLAM side via CMCP, read CM's CopperCraft Reference and MIB Definitions manual — all MIB groups beginning with cmCpe are implemented via CMCP.

We were originally thinking that CMCP allowed various configurable parameters to be set on the CPE, but as it turns out, that only applies to the fancier (and extremely rare) IAD and IMUX CPE models from CM, not to the common CR201 and not to Netopia SDSL CPE. CMCP operations that can be performed on the latter two CPE types are limited to the following:

A firmware update is clearly the most drastic thing that the DSLAM can do to a CPE device remotely via CMCP — see this page for a more detailed explanation of how it works.

Interaction with IMUX

As explained on the IMUX page, CM's DML scheme requires CMCP because they use it instead of the FRF.16 Link Integrity Protocol.

When used in conjunction with IMUX, CMCP functions separately on each bundle link rather than on the bundle as a whole. All payload packet belonging to the configured netmodel and encapsulation (including CM 1483) begin with the UNI/NNI fragmentation header like FRF.16 prescribes, but all CMCP packets (and no others) begin with 84 00.

Protocol details

Each CMCP packet is actually a CM 1483 bridged Ethernet packet, i.e., CMCP is layered over the bridged Ethernet encapsulation. Let's take another look at a CMCP packet:

Rx frame, length=54, flags: L F
0000:  84 00 AA AA  03 00 80 C2  00 07 00 00  FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 01 02 01  02 00 80 01  00 0B 01 5F
0030:  DA EC 00 00  58 7F

Here is just the Ethernet part of the same packet for the sake of clarity:

0000:                                         FF FF FF FF
0010:  FF FF FF FF  FF FF FF FF  00 1A AA AA  03 00 60 58
0020:  80 01 06 01  06 01 02 01  02 00 80 01  00 0B 01 5F
0030:  DA EC 00 00

We see MAC destination and source addresses consisting of all 1s, and then see that it is not a DIX Ethernet packet, but an IEEE 802 one with LLC and SNAP headers. Furthermore, the OUI code in the SNAP header (00-60-58) belongs to none other than Copper Mountain — compare it with the MAC addresses of CopperRocket CPE units.

Going back to the full CM 1483 packet, we see that the LLC and SNAP headers appear twice: first at the RFC 1483 level, then at the IEEE 802 level. CM has put their OUI in the second SNAP header, thus putting CMCP under the bridged Ethernet encapsulation. To me it would have been more natural to put the proprietary OUI in the first SNAP header (RFC 1483 level) and demultiplex the in-band management protocol at that level, but apparently CM's engineers looked at it differently.

The rest of the CMCP packet format past the second SNAP header is not understood by us at this time. If we decide to proceed further with the reverse engineering of CMCP in order to create our own open source implementation of DML, that project may require both of the following: