What is CM 1483

If you have spent any significant time looking into CM SDSL or IDSL, you have surely heard of what they call RFC 1483 encapsulation. What in the world is that? IETF RFC 1483 is titled Multiprotocol Encapsulation over ATM Adaptation Layer 5. It's an ATM RFC, yet we keep asserting that CM SDSL and IDSL lines never carry ATM to the subscriber. What's going on?

A more careful look at CM's product spec sheets shows them referring to RFC 1483 as Multi-Protocol Encapsulation over FUNI or ATM. Never mind that the IETF RFC makes no mention of FUNI, but all right, I'll cut them some slack because after all an inherent property of FUNI is that it can support anything that goes over AAL5 without any cooperation from the other end, and that would include RFC 1483. Netopia's references to CM's 1483 in their manuals also mention FUNI. Are they telling us in a back-handed way that the primary encapsulation on the SDSL bit stream is FUNI? Well, that is not quite the case. This is what a CM 1483 packet actually looks like in hex as it travels over the wire (captured with our Hack-o-Rocket):

Rx frame, length=56, 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  C5 86 5B 04  08 06 00 01  08 00 06 04
0020:  00 01 00 00  C5 86 5B 04  0A 00 00 01  00 00 00 00
0030:  00 00 0A 00  00 2A E4 39

There is a real RFC 1483 packet lurking in there all right (starting at octet offset 2), but what about the first two octets? Although the FUNI spec indeed calls for a 2-octet header preceding the AAL5 payload (where RFC 1483 would go), what CM has put in those two octets is not what the FUNI spec calls for. In fact I have not been able to figure out at all what that 84 00 is supposed to mean.

Since it does not correspond to any standard, the encapsulation in question is best thought of as CM 1483, CM's proprietary encapsulation.

But before we scream in horror at CM using a proprietary non-standard encapsulation on the line, let's take a closer look at the packet exhibited above, specifically the standard RFC 1483 part. It's a bridged Ethernet packet, not a routed IP one! The question of how can a standard router deal with CM's non-standard proprietary encapsulation is therefore moot: this bridged encapsulation is not intended for routers at all, but for bridges like the CopperRocket. (At this point it would be prudent to refresh on the difference between routed and bridged DSL circuits.)

The only time a router (as opposed to a bridge) would get to deal with the CM 1483 encapsulation is if that router also contains a built-in bridge function and logically emulates a router behind a bridge configuration. Netopia R7100 is one such router, and an R7100 was in fact the originator of the packet exhibited above. It was configured at IP address 10.0.0.1 on the bridged Ethernet with netmask 255.0.0.0, and the packet we've captured is an ARP query for 10.0.0.42 generated in response to me pinging that address from the R7100's LAN side. If you want an open source router doing the same thing, just take a garden variety Ethernet-to-Ethernet router and put it behind a CopperRocket. The bottom line is we are dealing with a bridged DSL configuration, not a routed one.

Although we have yet to try it with the real DSLAM, playing with various menu selections on the R7100 configured for HTU-C operation and looking at what it sends out on the line with a Hack-o-Rocket syncing up as an HTU-R suggests very strongly that the CM 1483 encapsulation is strictly bridged, never routed. I could not get the R7100 to send out a CM 1483 packet in which the standard RFC 1483 part would be routed rather than bridged, and all indications are that there is no such animal.

The final conclusion thus is that what CM called RFC 1483 is basically a codename for CM bridged. So the next time you hear a CM DSLAM operator say we use RFC 1483 encapsulation, interpret it as them saying we configure our DSL circuits as bridged rather than routed.

Why?

Having figured out what CM 1483 is, the logical next question to ask is why. Namely, why were they so inconsistent? There are a few inconsistencies to be noted right off the bat:

With routed SDSL CM appears to have gone out of their way to accommodate direct connectivity to classic leased line routers (something to be commended greatly), yet for the bridged ones they had opted for a completely proprietary encapsulation.
Routed SDSL circuits seem to use RFC 1490 encapsulation for the most part, yet the bridged ones use something 1483-based.
CM had the complete freedom to devise whatever signal format they wanted for SDSL and they had chosen the traditional HDLC-framed bit stream over ATM. Yet when devising their proprietary bridging encapsulation (again something in which they had absolute freedom of design choices), they chose to base it on an ATM RFC.

I can understand CM giving completely different treatment to routed and bridged circuits. Bridged circuits have no precedent in the world of traditional leased lines — those are always routed. Bridged DSL circuits were really intended for unsophisticated users using dumb bridge CPE, so it was perfectly understandable for CM to make their bridged and routed circuits as different as night and day and to use a proprietary encapsulation on bridged circuits while adhering to standards as closely as possible on routed ones. But even given that consideration and having decided on using a markedly non-standard proprietary encapsulation for their bridged configuration, couldn't they have made their lives much simpler by being more consistent?

I can see one reason why CM might have chosen ATM RFC 1483 as their starting point whether they liked ATM or not: like it or not, the major DSL backhaul networks are ATM, and most used CM DSLAMs which turn up on eBay periodically (including the one we've got) feature WAN modules for ATM DS3. The funky CM 1483 encapsulation most definitely comes back to the ISP's backhaul router as standard RFC 1483 over an ATM PVC exactly per the real IETF RFC. But then if the same CM DSLAM on the same ATM backhaul serves a routed SDSL circuit on another port with the RFC 1490 encapsulation, it would most likely do an FRF.8 IWF and the circuit would still come back to the backhaul router as RFC 1483! If it comes back to the ISP as RFC 1483 whether the DSLAM does CM 1483 or RFC 1490, why didn't they just make their lives simpler, always use the same conversion and put a bridged RFC 1490 encapsulation on the line?

The last observation about backhaul issues immediately raises another interesting question. It appears that while ATM was the dominant backhaul configuration, Frame Relay backhaul was also supported. Doing FRF.8 to serve a line with FR encapsulation from an ATM backhaul is expected because that's what the whole industry does, but how about the other way around? What would happen if one tried to serve a bridged SDSL line with CM 1483 encapsulation from a DSLAM that operates with a CM-supported Frame Relay backhaul? Would it really do FRF.8 in reverse? I find that a little hard to believe.

And for that matter, what if one used an ADSL or G.shdsl line card (ATM cells to the subscriber) in a DSLAM with an FR backhaul? Would that work at all? Would it do FRF.8 in reverse? Or would it only work if one operates the DSLAM as an IP router (in which case it fully terminates all encapsulations internally) without doing any PVC cross-connects between the DSL ports and the FR backhaul? I would love to find some answers to these questions.