Subject: (usr-tc) AMI/D4 provisioning on CT1

From: Bryan Wann <[email-masked]>
Date: Sat, 22 Jan 2000 20:18:44 +0000

I don't like surprises.

	Especially when I order a CT1 provisioned with B8ZS/ESF, and on
the day of the turnup the switch tech tells me "oh, your stuff is
configured wrong, it needs to be set up for AMI and D4, the DTC
you're on can't do B8ZS/ESF on this T.  Don't worry, I set your stuff up
like everyone else's."

	AFAIK, it is a trunk-side circuit (don't hold me to this).  We
have no problem hitting 45333-50333 both local and long-distance dialing
into the TC at this POP, with an assortment of modems.

	Will AMI/D4 cause things to break, or should I contact the telco
and beg to have it reprovisioned for B8ZS/ESF?

---
Bryan Wann		[email-masked]	
CWIS Internet Services	http://www.cwis.net

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Sat, 22 Jan 2000 20:57:25 +0000

Thus spake Bryan Wann

>configured wrong, it needs to be set up for AMI and D4, the DTC you're
>on can't do B8ZS/ESF on this T.  Don't worry, I set your stuff up like
>everyone else's."

>have no problem hitting 45333-50333 both local and long-distance
>dialing into the TC at this POP, with an assortment of modems.

>and beg to have it reprovisioned for B8ZS/ESF?

How about a 6 week lead time and the day the circuits are supposed to be
turned up, "Oh, we don't have the right cards and cables at the switch,
so sorry."  We're at a week and counting past FOC with a 6 week lead
time...what do these telco's do during that 6 weeks?!

Anyway...you shouldn't see any problems with AMI/D4, if you're getting
45333-50333, you might be getting 46000-51000 with B8ZS/ESF or so, but
I'm not even sure about that.  I'd go ahead and not worry about fighting
with the telco on this one and be happy.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Clayton Zekelman <[email-masked]>
Date: Sat, 22 Jan 2000 21:45:07 +0000

We use only B8ZS/ESF on CT1's with Nortel DMS-100 switches.  Only the
oldest of DTC's on the DMS can't do B8ZS/ESF.  All the new ones (past 5
years or more) CAN do it.  

> "help" to the same address.  Do not use quotes in your message.
---
Clayton Zekelman
Managed Network Systems Inc. (MNSi)
875 Ouellette Avenue
Windsor, Ontario
N9A 4J6

tel. 519-985-8410
fax. 519-258-3009

-

---

From: Marshall Morgan <[email-masked]>
Date: Sun, 23 Jan 2000 01:33:48 +0000

If you are paying for it then get what you ordered. Period.  Ask them to change
it and in the mean time you will use the T1's provided.  They are a public
utility so make them work for you.

Marshall Morgan

Internet Doorway, Inc (aka NETDOOR)
http://www.netdoor.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bryan Wann
> Sent: Saturday, January 22, 2000 12:15 PM
> To: [email-masked]
> Subject: (usr-tc) AMI/D4 provisioning on CT1
>
>
> 	I don't like surprises.
>

-

---

From: Garlic <[email-masked]>
Date: Sun, 23 Jan 2000 19:24:43 +0000

Before you go demand they do something, make sure you are not going to waste your
time.

B8ZS is of no help on a CT1.  The purpose of B8ZS is to ensure timing by preventing
lots of consecutive zeros on the line.  This can't happen with a CT1.  The control
bits in each channel will ensure enough ones density to maintain timing.

ESF is better than D4 is you are doing monitoring of the line or are going to run
advanced diagnostics using test equipment. Not having ESF doesn't hurt untill you
have problems then its a benefit.  The bad news is that ESF requires that both ends
of the line be ESF capable.  Many switches aren't ESF capable on CT1s.

-

---

From: Bryan Wann <[email-masked]>
Date: Mon, 24 Jan 2000 17:41:58 +0000

> of the line be ESF capable.  Many switches aren't ESF capable on CT1s.

Garlic,

	Thanks, this is exactly what I was needing to know; if I would be
wasting my time for something that would have little noticable affect
other than making me look [more] like an demanding, irate asshole telco
customer.  
:-)

---

-

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 24 Jan 2000 17:50:02 +0000

Thus spake Bryan Wann
>customer.  :-)

I tend to be all for anything that causes ILECs problems, but this is
one that I'd probably bypass.  I might make a few calls and see if you
can confirm that the switch really can't do B8ZS/ESF...then maybe make a
few calls to various folks disparaging the telco for using outdated
technology, then probably drop it.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 25 Jan 2000 04:06:34 +0000

This isn't for garlic's benefit, as I don't interact or answer
questions from people who won't post under their name.  Life is too short
to waste time on such foolishness. But since he's posting gobs of
misinformation to the list, I'll explain for everyone else's benefit.

First bit of misleading information is that the control (signalling) bits
can somehow maintain ones density.  It should be obvious to a anyone that
this is impossible as the signalling bits need to have multiple
values if they are going to signal anything.  The only way the
signalling bits could enforce ones density would be if they were always
ones, and if the were, they wouldn't actually be able to signal
anything.

Second problem with the signalling bits is that they only occur every 6th
and 12th frames.  So even if they were always ones, they would only affect
ones density during those frames.

So "lots" (8) consecutive zero can and do occur on a CT1 line.  Without
B8ZS, the framer has to enforce ones density by stuffing ones, this
causes a drop in the S/N ratio.  (I seem to remember 4db as the figure,
but I don't have any reference material in front of me to back that
up.)  B8ZS is able to handle these strings of zeros by inserting a bipolar
violation that the receiver knows to remove.  Since B8ZS doesn't have to
force ones, it doesn't have the associated S/N degradation of AMI only.   

So try and get B8ZS if you can.

--
Aaron Nabil

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 25 Jan 2000 17:03:31 +0000

OK...you're closer than Garlic Whatziname...but still not quite there.
:)  I wish, I wish, I wish I knew of an online source for this printout
that I have in my hand...its *very* instructive about how T1's
work...but alas, you all will have to deal with my summarization.  :)

This just in <sound of teletype here>...found it online  :)
http://duracef.shout.net/~wildixon/telecom/t1/t1.html

Thus spake Aaron Nabil
>ones density during those frames.

Correct so far (assuming D4 framing of course...which is what was being
discussed, so a good assumption :)

>So "lots" (8) consecutive zero can and do occur on a CT1 line.  

Depends on the application.  With voice calls in the DS0's, the encoding
of the voice data into the DS0's actually enforces one's density
inherently.  The encoding algorithm won't generate bit patterns that
don't meet one's density requirements.

>Without B8ZS, the framer has to enforce ones density by stuffing ones,
>this causes a drop in the S/N ratio.  (I seem to remember 4db as the
>figure, but I don't have any reference material in front of me to back
>that up.)  

I don't know what it translates into as far as a db loss, but it eats up
one out of every eight bits of data meaning a loss of 192kbps on a T1
total...dropping the total useable bandwidth to 1.344Mbps

>B8ZS is able to handle these strings of zeros by inserting a bipolar
>violation that the receiver knows to remove.  

Actually, its two bipolar violations in a specific pattern...but you had
the right idea.  :)  The specific pattern is 00011011, with BPV's at the
4th and 7th bits.

>Since B8ZS doesn't have to force ones, it doesn't have the associated
>S/N degradation of AMI only.   

Actually...AMI doesn't have any S/N degradation.  I think you're
thinking of ZCS, or Zero Code Substitution (I've also seen it referred
to as simply "Ones Insertion").  Basically, with ZCS, the equipment jams
a bit to one to enforce the one's density...of course the receiving
equipment doesn't have any way to tell whether this bit was on because
of the data or because of the need to maintain one's density, so you
basically just cannot put any data into the bit used like this...this drops
the data rate down to 1.344Mbps as above.  Again, with voice encoding,
neither ZCS or B8ZS is really needed as the encoding won't generate
codes that don't meet one's density requirements...its when you get into
data transmision that you have to be concerned about one's density since
that can generate all zero's.

AMI, for what its worth, is pretty much universal on all T1's.
Basically, all AMI (Alternate Mark Inversion) means is that a "mark" or
one bit, has the opposite voltage polarity from the previous mark or one
bit.  If two successive marks (with 0 or more interveaning spaces or
zero bits) have the same voltage polarity, then you have a BiPolar
Violation (BPV).  As you can see...since B8ZS uses BPV's to indicate
an all zero timeslot, B8ZS assumes AMI.  :)

>So try and get B8ZS if you can.

If you're only running voice calls...B8ZS isn't really needed...now,
having ZCS enabled (as our telco did on some of their trunks at one
point) can cause some problems since that fairly significantly cuts down
the total bandwidth...you're gonna see speed drops in that case.  But as
long as ZCS is off, you should be OK as far as transmission speeds even
without B8ZS.

As someone else mentioned...if you have problems B8ZS and ESF will be
nice to have as they do have some trouble-shooting capabilities...but in
general operation...its not really a problem if all you're doing is
voice calls.

Now, when you go to ISDN PRI, you have to have B8ZS with ESF because at
that point you're encoding data onto the circuit which can result in
all-zero timeslots.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 25 Jan 2000 20:26:28 +0000

> discussed, so a good assumption :)

Gee, thanks.  Nice to know that "I'm closer than Garlic Whatziname", and
that I haven't managed to make any major blunders in my first sentence.

I don't know why you'd say "assuming D4 of course" as RBS occurs at the 
same rate in both D4 and ESF.  

> don't meet one's density requirements.

Are you talking about CCITT mu-law encoding?  Sure, CCITT mu-law enforces
ones-density IN A SINGLE PCM CHANNEL.  But when you stack mulitple
channels together into a T1, how is one PCM channel supposed to know
what's in the next channel?  Well, it doesn't, and it's trivial to violate
ones density with something like +127 in the DS0 1 (1000 0000) and -126
(0000 0010) in DS0 2, as they are simply catenated together in the T1
frame.  1000 0000 0000 0010 has a run of 13 zeros.

> total...dropping the total useable bandwidth to 1.344Mbps

It only "eats" that bit in DATA.  In voice (modems), that bit is still
there, it's just noisy.

> the right idea.  :)  The specific pattern is 00011011, with BPV's at the

Yeah, I was simplifying.  In the context of the original message, I didn't
see any value in driving home and looking up the exact substitution value
in a reference book or on the web.  Obviously you did.  Good for you.

> the data rate down to 1.344Mbps as above.

I'm "thinking" of the two alternatives the original author had available
to him, a CT1 with B8ZS or without B8ZS (AMI only).  One has a poorer S/N
than the other.   

Your definition of ZCS (Zero code _supression_) would best be forgotten.
  
> Again, with voice encoding,

You are simply wrong.  You are again confusing ones density in a single
PCM channel with ones density in the T1 frame.

> . . .

Jeff, it's simply marvellous that you are able to use a search engine and
come up with these "answers".  In fact, it's a skill that I've wished
would be more commonplace on a majority of mailing lists (especially
inet-access).  But in future, note that there is a difference between
"knowing where to find something" and "knowing something".  Both very
useful, but in this case you are in the former category, not the latter.

--
Aaron Nabil

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 25 Jan 2000 21:00:58 +0000

Thus spake Aaron Nabil
>Gee, thanks.  Nice to know that "I'm closer than Garlic Whatziname",
>and that I haven't managed to make any major blunders in my first
>sentence.

>same rate in both D4 and ESF.  

Yeah...my apologies...mostly it was terminology thing.  Of course the
RBS occurs at the same rate in SF and ESF...didn't mean to imply
otherwise.  :)  Just that it would occur at the 6th, 12th, 18th, and
24th frame in ESF since ESF has 24 frames compared to SF's 12.  Same
diff really...mostly a terminology thing.

>Are you talking about CCITT mu-law encoding?  Sure, CCITT mu-law
>enforces ones-density IN A SINGLE PCM CHANNEL.  But when you stack
>mulitple channels together into a T1, how is one PCM channel supposed
>to know what's in the next channel?  Well, it doesn't, and it's trivial
>to violate ones density with something like +127 in the DS0 1 (1000
>0000) and -126 (0000 0010) in DS0 2, as they are simply catenated
>together in the T1 frame.  1000 0000 0000 0010 has a run of 13 zeros.

Uhm...ones-density requires no more than 15 consecutive zero's, so your
run of 13 is fine.  It also requires an minimum average of 12.5% of ones
(I don't know the period over which this average applies), which is
where the one in eight idea comes from I believe.

>It only "eats" that bit in DATA.  In voice (modems), that bit is still

True...the bit is still interpretted in voice applications...so its not
eaten per se...effectively, however, the bit is unuseable for practical
purposes...that's all I was trying to say there.

>Yeah, I was simplifying.  In the context of the original message, I
>didn't see any value in driving home and looking up the exact
>substitution value in a reference book or on the web.  Obviously you
>did.  Good for you.

Actually I waited until I got back to work since all my reference
material was at work...I didn't wait just so I could put the B8ZS
pattern though...I wanted to confirm a few other things.  :)

>Your definition of ZCS (Zero code _supression_) would best be

Dang...got that one wrong...my apologies...right idea...wrong acronym
expansion.

ZCS is almost never used any more...but it is something to be aware
of...as I said...I ran into some trunks that had it configured and were
causing considerable problems.

>PCM channel with ones density in the T1 frame.

Sorry...I'm well aware of the possibilities of interactions between
different DS0's in a frame...I am still correct though...mu-law encoding
will enforce ones-density (up to 15 consecutive zeros) on its own, with
no need for B8ZS (or the sucky ZCS).

>Jeff, it's simply marvellous that you are able to use a search engine
>and come up with these "answers".  In fact, it's a skill that I've
>wished would be more commonplace on a majority of mailing lists
>(especially inet-access).  But in future, note that there is a
>difference between "knowing where to find something" and "knowing
>something".  Both very useful, but in this case you are in the former
>category, not the latter.

Hey...I don't claim to be an expert on this...and I'll acknowledge that
I didn't communicate well here (and got at least one detail wrong)...but
I do have a fairly decent understanding of common T1 technologies.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Aaron Nabil <[email-masked]>
Date: Tue, 25 Jan 2000 22:14:52 +0000

> where the one in eight idea comes from I believe.

The original T1 spec was 3 ones in 24 bits, with no more than 15
zeros.  But the AT&T spec, (ie, the defacto standard) requires
one pulse every 8 bits, not just 3 every 24.

> purposes...that's all I was trying to say there.

The application in question _was_ a voice application, where it's
perfectly usable.  Surprising enough, the majority of T1's in the world
are carrying voice, so I would hardly call that bit "unusable for
practical purposes".

> Dang...got that one wrong...my apologies...right idea...wrong acronym

The reason I said it should be forgotten was because it is a term that has
different meaning in different contexts, of which your example would
almost always be the LEAST likely to be what someone meant.  Most
typically by ZCS people are referring to "a ZCS technique" like B8ZS, ZBTSI 
or HDB3, not one-stuffing done by a CSU.

--
Aaron Nabil

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 25 Jan 2000 23:50:21 +0000

Thus spake Aaron Nabil
>one pulse every 8 bits, not just 3 every 24.

Hrmm...all I can go on is my experience, what I've read, and what I've
talked to telco folks about...I have almost never heard it put as no
more than 8 zeros...virtually everyone I've talked to about it says it
can be up to 15 zeros.  This includes websites of many equipment vendors
that make this stuff (including at least Lucent, Motorola, Cisco, and
virtually every T1 tutorial/overview site that I've found...oh...and the
U.S.  Department of Agriculture...don't ask me why, but that one turned
up).

>or HDB3, not one-stuffing done by a CSU.

OK...again...I've never heard of ZCS used those other ways...only as the
bit-stuffing...though I have heard plenty of other terms for it as
well...I'll be careful in using that then...thanks for the warning.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Garlic <[email-masked]>
Date: Wed, 26 Jan 2000 01:10:19 +0000

So after you throw out all the crap and gobblegook that the others use, the
basic answer is still the same.

* For a CT1, B8ZS is of no value.  There is sufficent one's density for the
equipment to operate just fine without it.

* ESF is a diagnostic tool and is a good thing but a lot of voice equipment
doesn't have the capability.

As far as rest, the signal to noise ratio for this mailing list is one of the
poorest of the other equipment support lists that I subscribe to.   I would
have hoped this was a list of network professionals that were trying to help
each other.  Some participants seem to want to just be very caustic.

To the rest, I apologize for leaving off my signature if that's important to
you

Roy

-

---

From: [email-masked]
Date: Wed, 26 Jan 2000 17:21:21 +0000

U>Depends on the application.  With voice calls in the DS0's, the
U>encoding of the voice data into the DS0's actually enforces one's
U>density inherently.  The encoding algorithm won't generate bit
U>patterns that don't meet one's density requirements.

U>>Without B8ZS, the framer has to enforce ones density by stuffing
U>ones, >this causes a drop in the S/N ratio.  (I seem to remember 4db
U>as the >figure, but I don't have any reference material in front of me
U>to back >that up.)  

U>I don't know what it translates into as far as a db loss, but it eats
U>up one out of every eight bits of data meaning a loss of 192kbps on a
U>T1 total...dropping the total useable bandwidth to 1.344Mbps

Not quite.  AMI has nothing to do with the amount of available bandwith 
per se'.  What is getting mixed up here is that folks are assuming 
inband signalling (i.e. Robbed Bit Signalling) equals AMI.  This is not 
true.  RBS equals CTI because there is no out of band signalling like a 
D channel on a PRI for a CTI T-1.  Thus A/B bit inband signalling is 
used.  Now RBS does eat ever so slightly into the S/N ratio because in 
teh 6/12th timeslots the Least Significant Bit (LSB) is used out of the 
64kbs PCM encoding process for each channel.  Thus you have 56kbs of PCM 
data instead of 64kbs.  How much does that equate to on the S/N ratio ?  
There are two answers to this.  First if the samlping values of the lost 
PCM bits is lower than the ambient noise of the local facility connected 
to them, then you probably will see no S/N degredation (a likely 
scenario).  Otherwise there might be some but since the data 
transmission power level used is also much higher than the lost PCM 
bits, the effect should be neglible.

Jeff Binkley
ASA Network Computing

CMPQwk 1.42 9999

-

---

From: Brian Burgmeier <[email-masked]>
Date: Thu, 27 Jan 2000 00:56:46 +0000

We are in the process of merging two ISPs.  Our ISP runs on
the 3Com Hiper Arch Chassis the other ISP runs on Ascend.
Since we both use ELI for our Channelized T-1s we are
considering porting their dial in number over to our 3Com chassis
at our location..
What problems should we anticipate moving customers from
an ASCEND unit to 3com?  Both are using the "V90 standard."
protocol.  Would we be better off using
their ASCEND equipment?  Any feedback is appreciated.

Thanks -Brian

---

From: Tatai SV Krishnan <[email-masked]>
Date: Thu, 27 Jan 2000 15:07:26 +0000

> considering porting their dial in number over to our 3Com chassis

Regular dialup should not have any problems, however, Ascend uses radius 
attributes that are speicific to certain versions and its radius 
attributes overlap standard attributes. Other than that you should not 
have any other problems. 

Oh, one other - modems that connect v.90 (but actually connection k56 ) 
would have problems with v90 if not using the correct protocol.

> their ASCEND equipment?  Any feedback is appreciated.

No just use 3com its better....:-)

krish

-

---

From: Brian Elfert <[email-masked]>
Date: Thu, 27 Jan 2000 19:09:12 +0000

> No just use 3com its better....:-)

Personally, I'd be much more likely to continue to use 3Com if somebody
from logistics would ever call me with an RMA for my bad Dual PRI NAC.

Brian

-

---

From: "The NOC (COX Internet)" <[email-masked]>
Date: Fri, 28 Jan 2000 17:42:52 +0000

Brian,

We are having to make the same decision.  Our decision is to move everything
over to Ascend Maxes because they are a much more stabile unit than the 3Com
gear.  We hardly ever have any problems with our Maxes yet it seems like we
always have issues with the 3Com TCH.  Also, Ascend (now called Lucent)
doesn't have as many problems with v.90 and very few problems with the
Rockwell chipset.  And Lucent's support is better than 3coms.

Bryan
NOC Technician
COX Internet

----- Original Message -----
From: "Brian Burgmeier" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 26, 2000 5:06 PM
Subject: (usr-tc) Ascend to 3com

-