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.

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.

Other users of Flavor B

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 is very vanilla: the data rate, the quat orientation, the data inversion option (see below) and HTU-C vs. HTU-R operation are explicitly configured. The TNT also appears to have a CM emulation mode.

One can see a few other brands mentioned in the documentation for various existing SDSL CPE. A good example of a DSLAM vendor-neutral Flavor B CPE device supporting CM, Ascend/Lucent TNT and some lesser brands is Xpeed.

Providing the following configurable options should be sufficient in order to support all implementations of Flavor B:

• All possible data rates.
• Either sign bit first or magnitude bit first.
• Xpeed provides a data inversion option reminiscent of the inverted HDLC trick used on T1 lines before B8ZS. If we take Xpeed's support for this option as an indication that it's used by some DSLAM brands, perhaps we should implement it too.

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.

Some practical experience is needed to determine how serious this problem really is and what would be a good solution.