The description of the EncapsulationType object
in cmIfaceTable in CM's documentation is not very clear
on some points; this page is intended to serve as a clarification.
(Read CM's documentation first though.)
rfc1483 and rfc1490
These settings may be applied to DSL ports and to WAN virtual circuits. While the setting distinguishes quite clearly between the 1483 and 1490 options, each RFC encapsulation may be either routed or bridged, and that's where things get murky.
When either setting is applied to an SDSL/IDSL port in a netmodel that
allows it,
the result is always the bridged version of 1483 or 1490, never routed.
Additionally the DLCI number is fixed: 16 for rfc1490 or
528 for rfc1483 as explained on our
CM 1483 page.
The DSLAM also supports DSL types that use ATM: ADSL and
G.shdsl.
These are expected to use rfc1483 for the standard
RFC 1483 encapsulation; I don't know what would happen if someone
tried to configure rfc1490.
The situation is more complex for WAN VC interfaces. There are two issues to consider:
RFC 1483 is natural for ATM, RFC 1490 is natural for FR.
What would happen if someone tried to configure the wrong
encapsulation
on a WAN VC? Would the DSLAM support that?
I don't know the answer, but from my viewpoint it doesn't really matter.
What matters is that the DSLAM supports the right
encapsulation
for each physical medium type it connects to, and because these WAN links
are on the ISP's side, not on the user side, if some ISP decides to
configure the wrong
encapsulation, it's their problem, not ours.
The encapsulation type settings in question imply the routed form in the IP netmodel and the bridged form in the VWAN netmodel. We don't know about CopperVPN and HDIA.
Neither rfc1483 nor rfc1490 is allowed on
DSL ports in the cross-connect netmodel.
To serve out RFC 1490 use Q922-1490 described below;
to serve out CM 1483 use the VWAN netmodel in the point-to-point
configuration as described here.
IP-1490
This setting for the EncapsulationType object
is known to the rather old software version (L3.0) installed on our
ex-NorthPoint DSLAM.
However, attempting to set this encapsulation on a DSL port in the IP netmodel
barfs with an error message: Encapsulation not valid with this netmodel
.
(Update: R8.0 software does the same thing.)
Further experiments have revealed that this setting is only supported
with the HDIA netmodel and even then only on the special
voice VC 22.
The latter actually requires IP-1490 and won't accept
rfc1490 or rfc1483!
Is the IP-1490 encapsulation on VC 22 in HDIA netmodel
a viable way to serve out routed DSL circuits?
No, unfortunately it isn't: the NetMask setting is restricted
to 255.255.255.255 only, i.e., only one IP address may be routed to the
circuit, and one can't use the IP routing table because the HDIA netmodel
is isolated from the DSLAM's main IP stack.
Furthermore, the HDIA netmodel requires a DS3 or equivalent WAN VC, not
Ethernet, so one may as well use the cross-connect netmodel.
MAC-1483, MAC-1490 and IP-1483
None of these 3 settings are known to our old DSLAM software versions,
but the manuals for Version 7.0 talk about them.
It appears that these 3 new settings plus the IP-1490 setting
inherited from the old HDIA netmodel are intended for the new CopperVPN
netmodel which supposedly allows an explicit choice of MAC or IP encapsulation
on both WAN and DSL sides.
We now have a copy of R8.0 software installed on our SCM3 card, but the
motivation to play with the ugly CopperVPN netmodel just isn't there.
Q922 and Q922-1490
These settings are allowed only on DSL ports in the cross-connect netmodel and configure the port for per-VC cross-connect as explained here.
The only difference between Q922 and Q922-1490
as far as we can tell is that if the cross-connected WAN VC runs over ATM
and thus uses RFC 1483, the latter setting will invoke
FRF.8 conversion between 1483 and 1490
encapsulations, whereas the former setting won't.
The two settings otherwise appear to be equivalent.
HDLC and PPP-HDLC
These settings are allowed only on DSL ports in the cross-connect
netmodel and configure the port to be cross-connected as a single unit
without VCs.
The HDLC setting will cause the entire HDLC payload between
the opening flag and the FCS to be transported over the WAN VC; the
other setting (PPP-HDLC) allows one to serve out straight PPP
(RFC 1662) from PPPoA or PPPoFR as explained in CM's documentation.