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, yes and no.
FUNI works by taking the AAL5 CPCS-PDU (an ATM-ism) and stuffing it into
the HDLC frame with a Q.922 header prepended.
The Q.922 header used in FUNI is compatible with Frame Relay, so at least
in theory one could mix FR and FUNI VCs on the same HDLC interface, but the
10 bits normally used to encode the DLCI in FR are used to encode the VPI
and VCI in FUNI.
The Q.922 header used in CM's 1483 encapsulation is 84 00
or 84 01 (see below): per standard FR interpretation
it means DLCI 528; per FUNI interpretation it means VPI 1 and
VCI 32.
ATM RFC 1483 is concerned with what goes into the AAL5 CPCS-PDU, hence
in the context of FUNI it begins to apply after the Q.922 header, i.e., after
the first 2 octets.
The RFC specifies the encapsulation for a number of different packet types,
including routed IP and bridged Ethernet, and in fact specifies two different
encapsulation variants for each, called LLC Encapsulation
and
VC Based Multiplexing
.
Thus claiming to use RFC 1483 encapsulation without indicating the
variant used constitutes insufficient/dishonest documentation.
CM's 1483 encapsulation always involves bridged Ethernet packets,
never routed IP, and uses the LLC Encapsulation
variant.
CM DSLAMs don't really support FUNI outside of the very special case of their internally-terminated bridged encapsulation. That is, one cannot declare the primary encapsulation on a port to be FUNI and then assign various ATM virtual circuits to it from various netmodels at any given VPI/VCI. Instead the CM 1483 encapsulation is always served out at the same Q.922 address (view it as a DLCI or as VPI/VCI as you prefer) and only on CM's terms, not on the operator's terms. This encapsulation was clearly intended for use only by the proprietary CPE made by CM and their close buddies like Netopia, not by any standard FUNI implementations. CM explicitly supported other options for standards-based CPE, see our encapsulations page.
Since CM doesn't really support FUNI in the generic sense, it's better to think in FR terms — aside from the oddity of using an encapsulation based on RFC 1483 for their proprietary stuff for reasons we may never know, their approach is otherwise totally FR-based. Their preferred encapsulations in every other case are FR-based and they identify virtual circuits by DLCIs, not by VPI/VCI. (In fact they are so FR-centric that when dealing with native ATM interfaces they invent fake DLCI numbers that exist only inside the DSLAM and convert them to VPI/VCI used on the actual interface at the lowest possible level using a totally arbitrary mapping!)
All SDSL port encapsulations that support FR VCs reserve DLCI 528 for CM 1483 in that only CM 1483 packets are allowed to travel on this VC. These packets are always bridged Ethernet, never routed IP, and are used for the following two purposes:
The main payload travels on this VC when a bridged SDSL circuit is
configured with EncapsulationType=rfc1483.
This encapsulation type is set at the port level and precludes any other
VCs from existing on that port, hence CM's documentation doesn't dwell
much on using DLCI 528 (or VPI 1, VCI 32) and instead
treats the port as having no virtual circuits at all.
CMCP is layered on top of CM 1483 on the same DLCI 528, i.e., each CMCP packet is contained within a bridged Ethernet packet. CMCP can coexist with almost every other encapsulation type on the same port.
CM 1483 bridged encapsulation was clearly intended to be used together with CMCP. Anyone who is interested in implementing CM 1483 should be prepared to implement CMCP too: if you don't implement CMCP, the ISP needs to disable it on the DSLAM, and if you have to get them involved at that level, you may as well ask them to switch to standard RFC 1490 encapsulation as explained here.
Like most forms of HDLC, Q.922 uses the least significant bit of every address octet to indicate the length of the address: 1 in the last octet, 0 in all preceding octets. Thus a standard two-octet Q.922 address has 0 in the LSB of the first octet and 1 in the LSB of the second octet. The FUNI spec calls for the same. However, CM 1483 violates this rule sometimes.
It appears that CM's original implementation put 84 00
in the Q.922 header, and this header style got enshrined in CPE implementations,
both CM's own and Netopia's.
Then apparently CM had realized their error — not that it really matters
in my mind, given that this whole encapsulation is best thought of as
CM's proprietary, but apparently CM felt compelled to fix it, so they did.
And so they were apparently stuck with supporting both header formats.
Our DSLAM with software version L3.0 behaves as follows: as explained on
the CMCP page, lines configured with CMCP enabled
initially transmit nothing but an endless cycle of CMCP packets until a CMCP
response is received, and these initial CMCP packets are sent duplicated,
first with 84 00, then with 84 01.
Since we don't have a CMCP implementation to send the required response,
nothing else is ever seen on the line in this configuration.
(We are not yet set up to sniff the traffic in both directions between
the DSLAM and a piece of existing CPE.)
On the other hand, all CM 1483 packets that we have observed on
test lines provisioned with CMCP disabled had 84 01
headers.
In our previous round of experiments (before we had the DSLAM up and
running) we had our Hack-o-Rocket connected to a Netopia R7100 configured
as an HTU-C, and all CM 1483 packets we saw in that experiment had
84 00 headers.
A hex dump is worth a thousand words. Here is the pair of CMCP packets that gets sent on the line repeatedly until the needed response is received:
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
Here is an ARP packet on a non-CMCP CM 1483 line:
Rx frame, length=56, flags: L F 0000: 84 01 AA AA 03 00 80 C2 00 07 00 00 FF FF FF FF 0010: FF FF 02 60 58 00 00 03 08 06 00 01 08 00 06 04 0020: 00 01 02 60 58 00 00 03 AC 16 04 01 00 00 00 00 0030: 00 00 AC 16 04 03 CC ED
Here is an IP packet (still under the bridged Ethernet encapsulation):
Rx frame, length=112, flags: L F 0000: 84 01 AA AA 03 00 80 C2 00 07 00 00 00 00 86 15 0010: A4 E1 02 60 58 00 00 03 08 00 45 00 00 54 63 15 0020: 00 00 FE 01 4D 9C D0 DD 8B 01 AC 16 04 02 08 00 0030: 11 EA 68 07 00 00 F2 FD 4F 4A 50 C3 00 00 08 09 0040: 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 0050: 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 0060: 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 11 09
Here is an ARP packet transmitted by a Netopia R7100 acting as an HTU-C:
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
Here is a CMCP packet sent by the same R7100:
Rx frame, length=60, 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 20 AA AA 03 00 60 58 0020: 80 01 00 00 00 00 00 00 00 00 80 01 00 0E 00 00 0030: 00 00 00 00 00 00 C5 86 5B 04 EB CE
Is there a routed variant of CM 1483?
Well, let's refine the question.
If the question is whether it is possible to configure the DSLAM such
that the CPE will see a Q.922 header followed by a routed RFC 1483
LLC header, the answer is yes.
The simplest way to do that would probably be to set the
netmodel to cross-connect,
set the encapsulation type to Q922
(not Q922-1490, this way the FRF.8 conversion is
disabled)
and use cmSubIfaceTable to cross-connect some DLCI on the
SDSL port to a DS3/ATM VC carrying routed RFC 1483.
It is also possible that
CopperVPN Version 7.0
might allow serving out something to the effect of routed CM 1483
with EncapsulationType=IP-1483.
However, there is absolutely no need to worry about any ISP doing that
to you because this kind of routed CM 1483
has never been
officially supported or endorsed to our knowledge and no existing SDSL CPE
supports such a thing.
The proper
encapsulation endorsed by CM for routed SDSL circuits
and the one implemented by existing CPE routers like Netopia R7100
is RFC 1490 as explained
here.