T1: A Survival Guide
What a great age we live in, where you can teach YOURSELF your entire profession! As a self-taught network engineer with a major market data firm, I have great respect for some of today's tech writers who have single handedly taught me TCP/IP, Ethernet, Cisco routers, and Linux! The only aspect of my job for which I have had to rely solely on experience, (and the meager amount of information on the web) is T1s and synchronous circuits/leased lines. As far as I know, the only books which discussed the technical details of T1 and synchronous circuits are general telecommuncations text books. None are written from a contemporary network administrator's point of view. So, you understand my excitement at seeing O'Reilly take a stab at just such a book!
The book starts off at a good pace, talking about the history of the telephone network and its evolution into the digital age (the reason we have T1 available as a data service). It discusses the different terminology related to T1's, and the equipment that connects them to our routers, but makes very few analogies or examples to solidify the relationship of these terms to each other or to the big picture of networking. After discussing the physical and logical layout of T1 and its physical interface with our routers, Gast spends the next 40 pages on the nitty gritty details of T1: Timing, Framing, Coding, and the lights on the CSU/DSU. All the important aspects of T1 are discussed in a logical order. Unfortunately, it's not enough; Gast breezes through the most important and mysterious aspects of T1 without so much as one good analogy or explanation to develop the ideas. The diagrams are equally disappointing. They have a lot of information, but do little to clarify the subject matter. The T1 framing sections, especially did not get enough attention. This is the heart of T1, and really wasn't explained well enough.
After getting what seemed to be an introduction to the subject matter, I expected the rest of the book to go into further detail about the intricacies of T1 framing and coding, and ways to hash out possible problems on T1 circuits. Instead, the next 60 pages give the boring and useless details of the three most common link-layer protocols run over T1s: HDLC, PPP, and Frame Relay. Gast continues to litter the pages with confusing and uninformative diagrams, and then spends time explaining the details of each one step-by-step. Good diagrams don't need step-by-step explanation; they speak for themselves!
The level of detail he goes into for each of these protocols is similar to what you might find in a general Data Networking text. He discusses different principles of data communication as well as the specific frame formats of these protocols, but doesn't explain how these protocols specifically interact with T1. Although he gives the frame formats of these different WAN protocols, he doesn't give enough information or suggestions on using the information in any effective way. The oversimplification of many of the diagrams makes the book less useful than the RFCs which will give you the exact frame formats.
Gast assumes that if you don't work for one of the telcos, the only way you may come across a T1 is as a small business network administrator responsible for maintaining internet access via T1. That is not the case anymore; many large companies manage their own backbone and have access to leased lines, and T1 testers. The only time a T1 tester is mentioned, it's described as 'a handheld device with lots of buttons and blinking lights on it.' The principles behind T1 testing are quickly covered, but the intricacies of testing T1s and using T1 testers are not. This is unfortunate, as many Cisco routers have built in test pattern generation and loopback capabilities! (As do most standalone CSU/DSUs.)
It's obvious, as it is in many poorly written tech books, that the author knows his subject! The problem is, he doesn't consider the fact that we, the reader, may not. The book wasn't a complete waste of time; there is a lot of good information in here. Information on signaling and different types of alarms on T1s is present. The majority of it is just not explained very well, and too much time is spent on the link-layer protocols. I probably wouldn't be so down on this book if it didn't have O'Reilly's name on it.
You can purchase T1: A Survival Guide from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
Cisco Connection Online is the bomb.
Granted you have to dig quite a bit to find what you need, but it is all there. Everything you wanted to know, diagrams, how stuff connects to other devices, etc., all can be found there. I am not a Cisco employee, but I hit that site everyday during the course of my job.
Just curious, if you read this post, what exactly were you looking for? Specifics, not in general, maybe we can help you find what you are looking for.
Sent from your iPad.
Pretty much my assessment as well. With no practical line-level debugging information, I came away with little more than a gift-book for the half-priced book stores.
;)
Some practical information about using a "T-bird" device would have been helpful -- even more helpful would have been something that would suggest a "build your own t-bird tester from spare vacuum cleaner parts and save a bundle"
Whenever we've had serious problems -- rolls, flips, and bad CSU-DSU cards in the demarc, its either through trial and error "lets see is this really the TX pair? and is it polarity right?" -- or we beg, threaten, bully the CLEC test-and-turn up crew to send out a lineman, who invariably shows up with a t-bird box and pin points where the issue is.
Something also seriously lacking is some other non-protocol uses for T1 splitting, such as slicing Channelized T1 for voice, data.
All in all, save your O'reilly bucks for something you really need
Old age and treachery almost always overcome youth and skill.
The reason so little time is spent on the details of T1 framing and coding is because it's really simple. T1 is hard for many people to understand because they try and make it hard. Coding is really simple. Framing is simple as well. It never changes. Moreimportantly, the guy on the other end of the line troubleshooting the circuit probably won't know how to fix it. Once you know what RED, YELLOW/AIS/BLUE alarms are and what they really mean is going on you can solve T1 problems very quickly.
As for test equipment, what test equipment do you want information for? There are several test boxes just in the T-bird family, and each one has a different setup. It would make the book rediculously large to cover them all, and then people would bitch because it didn't cover digital lightwave test equipment, etc.
http://www.cisco.com/warp/public/116/t1_flchrt_mai n.html
Flowcharts, etc. T1s are hard if you make them hard. Or if you use Bay routers :)
Don't Panic...
The best way to go is surf around on the net and find an intro-level T1 howto-- this is a good one. You'll also need some hardware to start up with--the small Intel routers are nice and easy to set up. Sangoma cards are great if you are comfortable with Linux. Unfortunately, though, the documentation that comes with both of these are less-than-helpful unless you have a basic understanding of T1 stuff, which is best reaped from the web.
Looks like inerresting geek food.
(almost) Everything you Need to Know About T1s
Ancient tech, dating back to the '60s D1 circuits. I believe there was an F1 as well which used frequency-division multiplexing (i.e. what cable does) instead of time-division multiplexing. That's a real pain in the ass because the filters get very complex, and time-division multiplexing is dead-simple these days.
Your line between your house and the CO is very simple. It's a pair of twisted copper wires with some control voltage singalling (-48VDC on-hook, ~-8VDC on-hook, ~90VAC ring). When it hits the CO though it gets filtered (400-4000Hz) and digitized (PCM I believe) at 8 bits/8kHz and stuffed into a channel on a T1 if it's heading out to another CO.
These days you usually have equipment between the FXO and the switch which strips off the high frequency data and gives that to a DSLAM/RedBack/etc. but this is about voice.
A single voice communication channel is referred to as a DS0 and codes at 64kbps (8 bits * 8000 samples/sec). There are 24 DS0s in a DS1 (the data specification of a T1 is a DS1). Every DS1 frame has a framing bit. So 24 * 8 + 1 is 193 bits. Those 193 bits are sent 8000 times a second to give you your raw DS1 speed of 1.544Mbps. The frame is reserved though so you really get a useful bandwidth of 1.536Mbps.
In the olden days T1 circuitry required the frame bit to always be a '1' to maintain sync. These days the endpoint circuitry has no trouble keeping sync and the frame bit is used for "out of band" signalling. You figure 1 free bit 8000 times a second, that's a nice 8kbps of "free" information. This OOB channel is used to talk to the remote end to do things like loopback, QoS checks, etc. since it does not interfere with the data travelling in the 24 individual DS0 (data) channels. Pretty neat trick.
Now the actual electrical signals travelling those distances aren't 0v and 1v; it'd be impossible to get any data across. One of the first methods of electrically transmitting the data was AMI - Alternate Mark Inversion. A 0 (space) would be sent as no pulse, and a 1 (mark) would be sent as a pulse in the opposite direction of the last pulse. This kept the net DC voltage on the line at 0V (important for clock recovery), and simple flip-flip circuitry could be implemented to detect a bipolar violation (two consecutive pulses in the same direction).
Back when T1s were used ONLY for voice, nobody had to worry about long strings of 0s since it was statistically impossible to keep a PCM-coded voice channel at absolute zero, and the forced-1 state of the frame bit kept the framer in sync. Nowdays though T1s can carry data and it is easily possible to have long strings of 1s or 0s. Something had to be done.
With a long string of 1s you get a long string of "+1 -1 +1 -1..." (alternate pulse for each mark, remember) -- no problem. However a zero was coded as the absence of a pulse which meant that a long string of zeros would tend to have the clock sync drift since there were no pulses to sync to. B8ZS was born.
B8ZS (Binary 8 Zero Substitution) used a trick already used in low speed, short-haul communications such as RS232: escapes. A run of 8 zeros is sent as a specific error: "+1 + 1 0 0 -1 -1 0 0." The circuitry on the other side would see two BPVs (Bipolar Violations) in that specific pattern and instead of flagging an error, it would spit out 00000000. DS3s do the same trick with B3ZS. (aside: DS3 = 7 DS2 = 4 DS1, or 672 phone lines on a pair of coax cables)
Let's skip back to voice for a second. Remember how you have 24 voice channels being sent in a T1? Well as described, there is no way to tell if the line is on-hook, off-hook, ringing or busy. The solution was to steal a bit from each channel every so often and use that bit to represent line state. Since you're actually pissing around with the data, it's called in-band signalling, and specifically here, robbed-bit signalling.
What the telcos did was design a new framing system that used 12 DS1 frames as it's frame. Take 12 of those 193 bit frames and ear-mark #1 and #6. Now when Frame #1 comes along you will ignore whatever the LSB was for each DS0 and instead inject an "A" bit. And when #6 comes along you will do the same but inject a "B" bit. This big frame (12 DS1 frames) became known as the Super Frame.
What a normal DS1 frame looks like: (F = frame, A = A bit, B = B bit, 0-7 = PCM-coded voice traffic)
And for DS1 Frame #1:DS1 Frame #6:See how each channel gets an A and B bit?
What they did with the A and B bits was inject line state. 2 bits = 4 states. Now the CO can give you a busy signal or a ringback tone.
The telcos didn't stop there; they went on to give us the Extended Super Frame -- 24 DS1 Frames where every 6th frame has the LSB of the DS0s robbed to give you A, B, C and D bits. Most implementations just have the C and D bits mirror the A and B bits for now, but now you have 16 states to describe each channel in a DS1. This type of in-band signalling is known as robbed-bit signalling and is the reason you're at 56kbps for dialup. The modems actually do try and sync up to the DS1 framing and detect the robbed bit signalling when they trainup but really it's not going to get you much more speed to try and code at 64kbps 5/6th of the time and 56kbps 1/6th of the time. This robbed-bit signalling is only used on POTS; in data it's unnecessary because with ISDN your control info is in a separate D channel and for channelized-T1 it's not necessary.
I always feel like I'm talking about wrestling when I talk about SupaFrames and Extended SupaFrames :-)
Voice is always channelized; there are discrete conversations that have nothing to do with each other jammed together and transmitted as a group. Data T1s can come in channelized and unchannelized varieties. Basically it is used to group voice and data on a single T1, or, like voice, to group unrelated data communications together in an aggregate link for more efficient transmission.
Say you have a T1 between two offices and you want a 128bps link too. Well each DS0 is 64k, right? So they can take two DS0s and "split them off" for data, passing the other 22 for voice calls between the PBXes or KSUs or whatnot. Or if you want two 256k data links to two different areas; it can be done with one physical T1 to the CO, and then two from there to the locations. That's all that channelizing is about; aggregating datastreams into one connection.
Oh yes, ISDN. You'll recall that ISDN BRI is 64kbps. Guess what? An ISDN B channel is just one DS0, with the signalling occupying part of a 4kbps D channel. You can get fancy with something called Non-Facillity Associated Signalling which lets you cluster up to 8 DS1s' worth of D channels into a single B channel; That's right, with the right equipment termination you can combine up to 191 B channel control signalling into a single 64kbps D channel. (I don't think it's called a D channel anymore but I'm not sure on this.) -- dialup ISPs use it to try and regain lines when using PRIs, since a normal ISDN PRI is 23 B channels and a D channel (i.e. you lose a DS0 to signalling).
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out) because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that. It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level. :-)
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it. Normally you have -130VDC on the line (supplied by the CO end) and the remote end (and any repeaters) get their power from the line. Pretty nifty. You can go up to 650 feet without powering the circuit if I remember correctly; unpowered DS1s are usually refered to as DSX1s.
Troubleshooting-wise you don't run into much these days. The CPE and CO ends almost always have serial ports and you snap on a laptop and ask it what's wrong or set up loopbacks and so on. The old days of having one end in a hot location and the other in shade and having that cause temp-related sync issues are long past.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail. :-)
The most important thing to know about T1's is that
the technology has been around since the 1960's and
that Telco personnel STILL don't know how it works.
It can still take a traditional telco six months to
install a line, and more than a year to get it working correctly.
For testing, I recommend having/using a T-Berd and
a Sage. The T-berd is what the Telco techs use, so
you can test with them, end-to-end, using compatible devices.
They won't acknowledge the validity of any any other device, and blame "your equipment".
The Sage will give you more information about obscure timing glitches, gather stats, and has a wide variety of tests. Running a test with a high
concentration of zeros will show noise glitches
on the line; running lots of ones will stress the repeaters and power supplies. Make sure your test
pattern does not violate the framing rules for your
circuit-you can't run all zeroes on a non-B8ZS circuit, it looks like a dead line!
Make sure you have a jack panel at the circuit end so you have a way of inserting and dropping out of
the circuit. Wire the jack panel so you can plug in
"looking in" both directions. Have a "copper loop" for testing; when the Telco blames your equipment, tell them you HAVE NO equipment, just a T-berd on one end, and a copper loop on the other, so the problem is THEIRS to fix.
I have a very good, proprietary, in-house textbook on T-1s which was originally published internally by New England Telephone (now Verizon). The lady that wrote it was excellent--she was so good at her job, they did the only reasonable thing they could--they FIRED her. I don't know how you can
get a copy, mine is STOLEN--but it has six chapters, labelled "T1 Fundamentals", "Station Equipment", "CO equipment", "Circuit Testing", "ANSI testing", and "Tech Talks". No front cover or publication#. Mine is not for sale.
If you call the Telco for service, and get a knowledgable tech (this is RARE), get him coffee and donuts and pump him for information. It may be
the only way to learn what you need. Be aware that Telco personnel use their own internal jargon
that bears no relationship to anything else in electronics--you will need to listen carefully, then translate the "telco--ese" into english.
Good luck with your T1's, and keep praying for a
better source of broadband than the phone company.
After all, they are the ones who have been PREVENTING communication for over 100 years....
... You can get fancy with something called Non-Facillity Associated Signalling which lets you cluster up to 8 DS1s' worth of D channels into a single B channel;
:-)
:-)
There's actually no(real) limit on how many DS1s are attached to a signalling channel short of logical size. I think it's a byte-wide field.
(I don't think it's called a D channel anymore but I'm not sure on this.)
At that point it's called an H channel, but I've never met someone that called it that.
I briefly mentioned DS2s and DS3s. A DS2 is just an aggregation of 4 DS1s. The data bandwidth is not exactly 4*1.536mbps (frame is stripped out)
A DS2 has it's own framing, although you'd be lucky to find someone in telco that knows how it works.
because there are some slop bits set aside because the individual T1s coming in will not be synchronized and the slop bits take care fo that.
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
It's the same with DS3s, which are made up of 7 DS2s. Not really exciting, because all the work was done at the DS0/DS1 level.
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
Electrically, a DS1 is usually sent as an HDSL circuit these days; there really aren't any T1s to speak of anymore. DS = Data Specification (IIRC), where a T1 is just a DS1 with the electrical spec glued to it.
To clarify: T1 is the spec for transmitting a DS1 over copper in the US. HDSL is commonly use to emulate T1.
Normally you have -130VDC on the line (supplied by the CO end)
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
So, there's almost everything you need to know about T1s. No need to buy a book that goes into the same detail.
Close. Here's what you _really_ need to know: The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
I'm not really sure what you mean by this. Clock is regenerated by the remote end points of a DS3. There is no clock information carried through the circuit at the DS1 level.
You're right, they're re-clocked. I had to review the DS3 aggregation notes from Cisco. It's DS3s which have the slop bits, I don't think DS2s do this (they re-time the DS1s) -- I've never really worked with an actual DS2 so I don't know for absolute sure.
No, a DS3 is a completely different beast, with its own framing,coding, and timing rules.
That's what I was getting at; the DS3s (well the ones which are used to aggregate anyway) have all kinds of funky things going on inside but none of it is really all that interesting (at least not to me).
Um, no. Voltage supplied at the CO is completely determined by how many repeaters are on the line. You should end up with something like 12 volts at the CPE. -130VDc at the CPE would burn up just about anything you put on it, and would definately screw up a sinsitive test set.
This is incorrect. I just measured across the HDSL circuit here. -126VDC, no repeaters that I know of (3km circuit). Circuits in parallel (essentially what we have here) have equal voltage across them. Having to engineer the voltage for every circuit would be a royal pain in the ass. Actually for fun, take your HDSL CPE end, and take a good autotransformer and diode bridge. Connect the diode bridge + and - to T and R (polarity doesn't matter) -- now slowly bring up the autotransformer. The CPE end won't even light up until around 85V or so.
The guy at the telco almost certainly does NOT know how this stuff _really_ works. I've had to explain alarm codes to more than one "senior engineer". DON'T let him get off the phone. If he doesn't have a test set, hold on the phone until he does. Escalation is your friend.
haha, yes you are very correct here. Find someone and find some way to get their pager, cell and office numbers. And hold on to them because a good tech is very hard to find.
As far as I know, the only books which discussed the technical details of T1 and synchronous circuits are general telecommuncations text books.
There's a good bit of info on T1 lines in some of the professional level cisco cert study guides... also, here's an interesting paper on everything you wanted to know about T1, but were afraid to ask.
The higher voltages is how it gets through all of the distance.
Incorrect; the voltage is only used to power repeaters and the CPE; the actual data transmission is done with low-voltage signals. If you increase the voltage swing or push more current, you end up increasing crosstalk and that brings you bigger troubles, which is why they use repeaters in the first place. It's the use of repeaters which give you the incredible distances that T1/E1 circuits can span, and the repeaters rely on the static -130VDC on the line.
Fibre-optic transocean lines do the same thing. You don't want to cut through a long-haul fibre line because they have thousands of volts across a couple of their internal metal layers to provide power for the ocean-floor optical repeaters.
While most repeaters take the -130V provided across the T/R and generate their own internal power supplies from it, some types of repeaters will take a -48VDC power source and regenerate the -130VDC for the next 50km or so, just as the CO-end equipment does. The -130VDC is current-limited (you're running on thin wire remember) and as such it just doesn't go all that terribly far. Powered circuits are only there to make life easy in remote locations (you don't need power handy), not to make the signal stronger. That's what regeneration and repeaters are all about.