7 messages in net.nether.puck.cisco-nsp[c-nsp] Re: DS3 framing: M13 vs. C-bit
FromSent OnAttachments
John NeibergerJan 18, 2005 12:41 pm 
Michael K. SmithJan 18, 2005 1:16 pm 
james edwardsJan 18, 2005 1:34 pm 
dave o'learyJan 18, 2005 1:34 pm 
ringwyrm27Jan 18, 2005 3:08 pm 
Justin M. StreinerJan 18, 2005 3:14 pm 
MADMANJan 18, 2005 4:11 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] Re: DS3 framing: M13 vs. C-bitActions...
From:dave o'leary (dole@juniper.net)
Date:Jan 18, 2005 1:34:51 pm
List:net.nether.puck.cisco-nsp

At 10:16 AM 1/18/2005 -0800, Michael K. Smith wrote:

On 1/18/05 9:40 AM, "John Neiberger" <John.Neiberger at efirstbank.com> wrote:

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

either will work, but they should definitely be consistent end to end (both the equipment and the circuit settings). It is probably clock slips that you are seeing that cause the errors. In addition to the discussion that Michael pointed you to below, here is another useful reference page:

http://www.protocols.com/pbook/ds3.htm

You can ignore the latter part of the page which refers to the ATM specific mapping. The physical layer framing info on the first half of the page is relevant.

dave

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?

Here is a pretty good discussion of C-Bit vs. M1-3 from the archives.

http://puck.nether.net/lists/cisco-nsp/2393.html

I'm a bit surprised you can get the DS-3 to talk end-to-end with two different framing types. I would bet there are more than two circuits in play here. I have always heard C-Bit and B3ZS for Framing/Line-encoding on a data circuit. I *think* MI-3 is more for DS-1 over DS-3 purposes.

Mike

_______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/