[lug] [OT] WIC T1 or 56k

[Nate Duehr]

On Thu, 2002-09-26 at 00:28, TJ Schuler wrote:
> This is correct. A DS0 by definition in the US is a 64K channel - the
> difference between 56K and 64K is how the equipment handles the actual zeros
> and ones on the line. DS-1 lines require no more that 15 "0" bits before a
> "1" bit being sent. This is a requirement to keep timing on the line
> correct.

This is only true on D4 coded spans.  ESF coding on the spans move the
signaling bits out of band and you can run all the zeros or ones through
the channels you like.  Well, at least they "kinda" do... they make it
look to you like all your ones and zeros are there after passing them
through a "clear" 64K timeslot... 

How it does this is that most ESF spans are configured to also use
Bit-Eight-Zero-Supression (B8ZS) typically, and the equipment handles
this for you... yes, the right number of zeros and ones go out on the T1
line, but the zeros and ones the equipment inverted on the line to
follow the DS-1 rules are presented to the the DTE equipment properly
after being run through the algorithm.

The weird part about routers with internal DS1 interfaces is that each
manufacturer can choose to fiddle with the alarm and header bits and
whatnot as they please... allow the user to fiddle or not to fiddle,
etc.

So this generic discussion of the line codings may not apply to Cisco
specifically, as I don't know what they truly do... from what I've seen
they follow the telco and real-world specs pretty well and usually "just
work".

> Anyways one of the ways to do this is to make every 8th bit a "1" and only
> use the first 7 bits for the data. This is how we get 56K service with DDS.

Eeeek.  DDS.  I hated troubleshooting those things.

> The other way to do this is to use a mechanism like B8ZS, which replaces
> blocks of 8 zeros with the B8ZS code value. So you have a 64k timeslot but a
> certain amount is overhead, some say it is 56K usable - but it really
> varies.

Again, you don't "lose" anything with B8ZS.  The equipment inverts
certain ones and zeros on the physical line to match the rules, but
presents you a full 64K pipe that acts "normally" when this is done
properly.

> I like to use the example of videoconferencing of the WAN. In the old days
> with H.320 we used to channalize a T1 and use certain timeslots for data and
> certain for video.  Now this worked fine and looked alright the problem was
> that you couldn't ever use the "video" timeslots for data if they were not
> being utilized. This is similar to the 7/8 method used in DDS. Now with
> H.323 and Video over IP we can dynamically allocate the bandwidth to the
> video over the data timeslots and reclaim that bandwidth when not in
> use -works just as good if not better and a lot more flexible.

Back then, this was more a function of the way the timeslots were
allocated to DTE equipment than their suitability to carry different
types of data.  There were only VERY expensive ways to share time-slots
on DS-1's prior to everyone just jumping up a stack level and putting
everything over IP.  You could easily have purchased a monster Tadiran
or other manufacturer's mux that could be reconfigured as needed when
the video wasn't up, and you could also have scripted those changes, but
what a PAIN that would have been...

Most modern "we're using X amount of bandwidth for overhead" problems
are either... 
a) The span is D4/AMI.
b) The protocol RIDING on the span has overhead or signaling that has to
be accounted for in design of the network.

Now I never had to work on them, but for the curious... the reasoning
behind all these "there must be a certain number of ones and a certain
number of zeros" on a T1 circuit stems from OLD (very old, mostly long
gone except in rural areas where the Bell is too cheap to replace them)
digital repeaters that were line-powered... if you never had a voltage
swing... (too many zeros or too many ones all in a row), the thing would
lose power... and it would have to be kickstarted by some poor guy with
a battery pack in a manhole -- also the rules relate back to when
Phase-Locked-Loops weren't all that great at staying locked... hard to
keep a synchronous circuit going if the PLL's are unlocking all the time
and re-synching.

Nate