Flavor B is the nicest possible flavor of SDSL/2B1Q as it's the closest analogue to the traditional leased lines. In Flavor B a traditional synchronous serial HDLC bit stream with a traditional leased line encapsulation like Frame Relay or PPP is carried over a bare Bt8970 or RS8973 bitpump acting as the DSU.

Flavor B comes directly from Brooktree's application examples of how to use their bitpump chip standalone.

Copper Mountain variant

The most famous implementation of SDSL Flavor B is Copper Mountain SDSL. CM SDSL differs in the following main ways from a vanilla Flavor B system which one would get by following Brooktree's application examples most directly:

• The set of data rates used is a little odd.
• A pre-activation signal is transmitted on the line encoding the data rate so that CPE has no user configuration.
• The quat orientation is magnitude bit first rather than sign bit first.
• The encapsulations and service models get interesting at the higher level and a proprietary though optional line management protocol is implemented.

The full details about CM SDSL are given on this page.

Ascend/Lucent variant

Aside from CM, the only other user of Flavor B we know specifically is Ascend/Lucent TNT. There probably are/were some others, but we don't know them by name.

Judging from the available documentation, TNT's implementation of Flavor B seems very vanilla: the data rate, the quat orientation, the data inversion option (see below) and HTU-C vs. HTU-R operation are explicitly configured supposedly. The TNT also appears to have a CM emulation mode.

Our examination of Lucent's DSLPipe DSU has revealed however that at least in the default configuration the TNT probably does not use the CM emulation mode: the DSLPipe units were factory-configured for sign bit first, no pre-activation and data inversion enabled, and the manual included in the box does not document any of the internal jumpers which control these settings.

The data inversion option is weird. It is present in the XSB-2000 DSU and in Xpeed, and since it appears to be the default/standard configuration for the Ascend/Lucent flavor, we should definitely support it, but it is unclear why this option has been created in the first place. It was a classic trick on T1 lines before B8ZS: one could not have too many zeros in a row, but all ones was no problem. HDLC in the idle with flags configuration prevents long runs of 1s, so inverted HDLC prevented long runs of 0s which were bad for T1s without B8ZS. But why do that on SDSL/2B1Q where long runs of any constant symbol are eqaully bad and where LFSR scrambling is used to handle the problem?

Our OSDCU implementation

The implementation of Flavor B on our OSDCU should support all possible subflavors by way of these orthogonal configurable settings:

• All possible data rates.
• All supported pre-activation types.
• Either sign bit first or magnitude bit first.
• Data inversion on or off.

Implementation notes

Given that it's based directly on the no channel unit application examples provided by the bitpump chip vendor, implementation of Flavor B should be fairly straightforward. Read sections 3.3 through 3.10 of the ZipWire Software User Guide.

As we all know, HDLC can transmit either 1s or flags when idle; both ways should work fine with Flavor B, but at least CM's implementation has been found experimentally to transmit 1s when idle. If the initially-idle HDLC transmitter sends 1s, the exact point at which the _TRANSMIT_EXT_DATA API command is given doesn't really matter: it would throw the switch inside the bitpump from the internal 4-level scrambled ones to scrambled 4-level external data, but if the external data is all 1s at this point, the actual transmitted signal doesn't change. This extended preamble of scrambled 1s should be plenty enough for the other end's receiver to establish tip and ring. (See Tip/ring reversal.)

The link good criterion is a more difficult matter though. The ZipWire Software User Guide tells us that the LOS and NMR checks may not be sufficient for detecting a bad link condition and recommends tying the check to higher layers of the protocol stack, i.e., HDLC or even higher. The obvious problem with that of course is the violation of OSI layer separation.

In practical terms the link good criterion problem is really two separate problems:

1. The DSLAM is likely to have implemented some HDLC-based check to assure that the link is still up, and if so, our open source CPE implementation better make the DSLAM's check logic happy or else it would keep tearing the link down and retraining. This page explains how CM DSLAMs handle this matter.

2. In the opposite direction we may want to implement a check of our own to assure that the DSLAM's end of the link is still there. Obviously since this side is under our control, we have more leeway in the matter.