[c-nsp] Adtran MX-2800 to PA-MC-T3

[Brett Frankenberger]

On Tue, Aug 02, 2005 at 11:37:13AM -0400, Greg Boehnlein wrote:
> Yeah, that is what I've always thought. However, the PA-MC-T3 does not 
> seem to support M13.
> 
> core1.cleveland(config)#controller t3 1/0/0
> core1.clev(config-controller)#framing ?
>   auto-detect  Application Identification Channel Signal
>   c-bit        C-Bit Parity Framing
>   m23          M23 Framing Format

m23 and m13 are really the same thing with a different name.  The
actual multiplexing going on is four DS1s into a DS2, and then 7 DS2s
into a DS3.  So "m23" is a more accurate representation of the framing
that's happening (it's putting DS2s into a DS3 -- at the DS2->DS3
level, the multiplexor neither knows nor cares that the DS2s in question
are carrying four multiplexed DS1s).  Since most muxes these days take
DS1s in and put out a DS3 (and vice versa), and the DS2 level is
hidden from the user, the framing is commonly called "M13".  (The
MX-8200, then, is really seven DS1->DS2 multiplexors, and one DS2-DS3
multiplexor, in one box.)

> Am I missing something? Should M23 work w/ M13? 

Yes.  And that's the framing you should be using, although given your
configuration, you cBit might work.  

To address another message in the thread, the DS1s within a DS3 do not
all have to be in sync -- they are asychronously muxed into the DS3
(actualyl, into the DS2, which is then asynchronously muxed into the
DS3).  As long as the DS1 clocks are all within specficiation,
they can go into the DS3 just fine, whether or not they are all in
synch with each other.  In any case, DS1 level problems wouldn't cause
the T3 level errors you are seeing here.  And framing problems wouldn't
cause Line Code Violations, either -- those are more likely to be a
cabling problem or a level problem.

     -- Brett