Net to Net Technologies (now practically defunct and owned by Zhone) had produced a platform for DSL and for WAN connectivity in general which is quite obscure, but which we've been asked to look into.
The NTN platform is built on a principle that is essentially the direct opposite of what our Open WAN Connectivity Project is about. Whereas our project emphasizes non-Ethernet WAN media in their native non-Ethernet form, NTN's world view was very Ethernet-centric. At the heart of NTN's platform lies the NTNHDLC encapsulation: it is their method for carrying Ethernet over HDLC-based synchronous serial bit stream WAN media. NTN used this proprietary Ethernet encapsulation over every type of WAN media they had touched, ranging from xDSL ports to DS3/E3 backhaul links.
In addition to DSLAMs NTN had also made network extender
units,
and those were an implementation of NTNHDLC in its purest form.
These network extenders were offered for a wide variety of WAN media types
and always in pairs: a provider unit and a subscriber unit.
These units were offered in single and ganged versions, the latter being
a juxtaposition of several independent units in a single box with a single
power supply.
Each unit converted between the particular WAN media type and Ethernet.
An NTN DSLAM of any model (there was a wide selection from low to high end)
is nothing more than a collection of these network extender units (the
provider
version), one per line, and a fairly typical managed Ethernet
switch in front of them.
(These DSLAMs were not IP routers!
The marketing name IP DSLAM
seems to be deliberately misleading.)
The CPE for these DSL services was the subscriber
unit out of the
respective network extender
solution.
As the NTNHDLC encapsulation is totally non-standard, nothing standards-based
could ever be connected directly to an xDSL or T1 line served out of an
NTN DSLAM.
Furthermore, NTN's use of this proprietary Ethernet encapsulation extended
to the uplink interfaces as well!
Being Ethernet switches at the core, NTN DSLAMs want an Ethernet uplink.
Uplink interface modules were also offered for traditional backhaul types
like T1 and T3, but they are not standard T1/T3 interfaces.
Instead these modules implement the subscriber
side of the same old
Ethernet network extender
solution: a T1/T3 uplink interface module
can only be connected to a T1/T3 line served out of NTN's respective
provider
unit and not to a standard line of that physical type!
All in all, in the not-so-humble opinion of the hacker writing these web pages, the NTN DSL/WAN platform can be summed up in these 4 words: a piece of crap.
We have attempted to recover an understanding of the NTNHDLC encapsulation from the sole piece of NTN gear we've been given: an IPD12000 DSLAM chassis with 3 12-port line cards: one T1, one SDSL and one IDSL. Given that all 3 line cards exhibit the same architecture (12 per-line Ethernet-to-HDLC converters behind an Ethernet switch), we have every reason to believe that the NTNHDLC encapsulation is the same across the board, but the IDSL card was the easiest to hook up to (using our Hack-o-Rocket).
We have hooked the Hack-o-Rocket up to a line coming out of that IDSL line card, the ISDN link was established as soon as the line card sent out a TL tone, and when we put the time slot assigner on the rocket into 144 kbps IDSL mode (B1+B2+D) and enabled HDLC dump, we saw the following packets pouring out of the line ad nauseum:
Rx frame, length=34, flags: L F 0000: 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: E2 91
They are obviously status or management packets of some kind, but it is completely unknown what the CPE response is supposed to be, if anything.
Here is how actual Ethernet packets look in the NTNHDLC encapsulation:
Rx frame, length=62, flags: L F 0000: FF FF FF FF FF FF 00 00 C5 75 3B 24 08 06 00 01 0010: 08 00 06 04 00 01 00 00 C5 75 3B 24 D0 DD 8B 81 0020: 00 00 00 00 00 00 D0 DD 8B 0B 88 88 88 88 88 88 0030: 88 88 88 88 88 88 88 88 88 88 88 88 C0 7B Rx frame, length=62, flags: L F 0000: FF FF FF FF FF FF 00 00 C5 75 3B 24 08 06 00 01 0010: 08 00 06 04 00 01 00 00 C5 75 3B 24 D0 DD 8B 81 0020: 00 00 00 00 00 00 D0 DD 8B 34 88 88 88 88 88 88 0030: 88 88 88 88 88 88 88 88 88 88 88 88 1B A5 Rx frame, length=62, flags: L F 0000: FF FF FF FF FF FF 00 00 C5 75 3B 24 08 06 00 01 0010: 08 00 06 04 00 01 00 00 C5 75 3B 24 D0 DD 8B 81 0020: 00 00 00 00 00 00 D0 DD 8B A5 88 88 88 88 88 88 0030: 88 88 88 88 88 88 88 88 88 88 88 88 20 B2 Rx frame, length=81, flags: L F 0000: 08 00 2B 0D CB 19 00 00 C5 75 3B 24 08 00 45 00 0010: 00 41 05 F4 00 00 34 11 3F FD 4A 7D 9A 5E D0 DD 0020: 8B 02 FC 88 00 35 00 2D 57 68 E5 07 00 00 00 01 0030: 00 00 00 00 00 00 08 69 66 63 74 66 76 61 78 06 0040: 68 61 72 68 61 6E 03 6F 72 67 00 00 01 00 01 0B 0050: 30
As one can see, there is no header at the HDLC level (nothing like RFC 1490 bridged encapsulation or CM 1483), and the Ethernet header directly follows the opening flag. Such encapsulation is totally non-standard, but for someone like NTN who didn't care about anything other than their Ethernet converters connecting to the line it saves header bits...
The SDSL line card we've been given (labeled SAM2000-12
) features
Orion GS2216 chips — this facet got us
intrigued.
According to an old Orion datasheet we had found on
DatasheetArchive.com in late
2005 (the datasheet itself is dated June 25, 2002), GS2216 is supposed to be
the 2B1Q version, and we are naturally curious as to how did Orion
implement SDSL/2B1Q.
Unfortunately we haven't been able to get this line card to peep: a lineman's handset (aka buttset aka beige box) connected to its output heard silence. It thus appears that even if it does use the 2B1Q line code, the startup sequence must be something quite different from the familiar SDSL/2B1Q: either it puts out some non-audible frequencies like G.hs, or perhaps the STU-R must utter the first peep.