C-Bit has a channel in overhead called the MDL (maintenance data link) that
allows for the passing of FEAC codes like the FDL does on a T1. It also
allows for the passing of G.832 type messages (error counts and so on).
C-bit/MDL allows telco to perform remote testing on the DS-3 by logging into
a mux and just shooting the loop up/down codes down the MDL. I don't
believe that M13 allows for this.
----- Original Message -----
From: "John Neiberger" <John...@efirstbank.com>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, January 18, 2005 12:40 PM
Subject: [c-nsp] DS3 framing: M13 vs. C-bit
I don't have a lot of experience with DS3s and I have a minor problem
that I need some help with. We have a point-to-point DS3 with both
endpoints set to M13 framing (Cisco 7513 PA-T3+ and a Kentrox IDSU).
This link involves two service providers. Qwest says that we are
provisioned for M13, as well. However, Time Warner at the other end of
the link seems to think we're provisioned for C-bit. My question is
this: does that matter?
We see a highly intermittent burst of errors from time to time but
other than that we don't see a problem. It can run for days or weeks
without a single error and then we'll see a blip of a couple thousand
errors, after which it runs cleanly again. Is it possible that this
problem is caused because of c-bit being used on the Time Warner side of
that part of the link?
We have three potential courses of action:
1. Get Time Warner to switch to M13
2. Get Qwest to switch to c-bit and change our end devices to c-bit
3. Do nothing since the errors are brief and infrequent
What do you think? Could the framing mismatch cause a problem, perhaps
similar to an AMI/B8ZS mismatch in the DS1 world?
7 messages in net.nether.puck.cisco-nsp[c-nsp] Re: DS3 framing: M13 vs. C-bit
