Ref: 13680021
Title: Setting Up Encryption Units to Work With Internetwork Bridges
Date: 1/11/91

Copyright 3Com Corporation, 1991.  All rights reserved.

Encryption units, used for security purposes, scramble data bits into a
particular format before transmission, and unscramble them after
transmission.  Encryption units are often found in military environments.
Normally there is no problem using encryption units with low speed lines
(under 64 KB), but problems may occur on IB/3s with ITCM cards for T-1
lines.

Here is a typical setup of encryption units with Internetwork Bridges:

 Ethernet                                                        Ethernet
|--------|                                                      |--------|
     |                                                               |
   ------    ------------    -----  T1   -----    ------------    ------
  | IB/3 |--| Encryption |--| CSU |-----| CSU |--| Encryption |--| IB/3 |
  |      |  |    Unit    |  | DSU |     | DSU |  |    Unit    |  |      |
   ------    ------------    -----       -----    ------------    ------


Encryption units should work until they need to be re-sync'ed.  Problems
with encryption units are actually caused by "HDLC errors" rather than by
ones-density errors.

In the IB/3, the ITC/M inverts the data stream; this is the "ones density
mode" of the IB/3 T-1 Controller board and is not configurable.  By
doing HDLC zero insertion before data inversion, we "guarantee" ones
density (at least 3 ones in 24 bit times and no more than 16 consecutive
zeros).  However, the encryption device may expect to see HDLC zero
insertion (an HDLC flag of no more than 6 ones in a row).  If so, this can
be solved by the following cabling trick, combined with a change
in clock rate as described below.


The cabling trick:

This will re-invert the data stream so it looks like an HDLC data stream,
satisfying the encryption device's need to see HDLC.  It is performed at
both sites (at each end of the link).

   For V.35:    Swap the leads at the IB/3 end of the V.35 cables as
                follows--swap pin P (SDA) with pin S (SDB) and swap
                pin R (RDA) with pin T (RDB).

   For RS-449:  Swap the leads at the IB/3 end of the RS-449 cables as
                follows--swap pin 4 (SDA) with pin 22 (SDB) and swap pin
                6 (RDA) with pin 24 (RDB).


The clocking change:

This will allow the CSU/DSU to supply ones density, because the encryption
device has altered the bit stream from the IB/3, thereby preventing the IB/3
from ensuring ones density.

   Configure the CSU/DSU to provide clocking to the DTE at 1344 Mbps.
   The CSU/DSU will use the 200 Kbps remaining (1544 - 1344 = 200) to
   insert a one in the bit stream presented to the T-1 span every eighth
   clock pulse.


It should make no difference what T-1 framing method is used by the CSU/DSU,
as long as it is supported by the Telco (or other service provider of the
T-1 span).  The T-1 framing method is transparent to the IB/3.

The IB/3 does not "support" any kind of framing; it is the CSU/DSU which is
responsible for the insertion of framing before transmission of signal onto
the span and the removal of framing bits before presentation of the bit
stream to the IB/3.  So, as far as the IB/3 is concerned, it does not matter
if the framing method is D4 or ESF, or whether B8ZS is supported or required
by the Telco, etc.

Also, as long as the clocking is external, the baud rate parameter affects
only path cost computations for spanning tree and load balancing with
parallel lines; data is presented at the rate of the clock provided.
