> From: Charles Sprickman <spork@inch.com>
> Subject: Re: preferred DS3 framing
>
> This just gets more confusing as I find more info.
Yes, it just gets more confusing. One of the problems is the mixing
of telco terms based on the idea of (voice) channel banks and how
they're multiplexed onto a t3 with purely datacomm usage.
A t3 has a linecode and a framing. If you order a "clear channel"
t3 from a carrier, the carrier isn't supposed to care about the
framing and should be happy as long as you're using an appropriate
linecode (b3zs) or at least some coding convention that maintains
an acceptable run length.
Over that channel, you can also run C-bit or M13 framed data, where
you're imposing a structure on the data in the channel in terms
of header/overhead bits and ds1/ts2 channels (which may or may not
be used as such), all will work nicely as long as both of your
end agree, the provider agrees not to care and will only see alarms
on code-violations or loss-of-signal.
If you tell the carrier that it's a C-bit or M13 framed circuit or
they can only provide one of those options, then the provider will
provision their muxes or DACS accordingly and can see errors on
loss-of-framing. They may also be able to enable or interrogate
various test functions based on conventions for using the overhead
bits.
Between the two, C-bit has better provision for end-end testing and
error reporting at the ds3 level, you can obtain various performace
data as seen from the *far end* at your near end CSU. M13 framing
has more provision for requesting test functions at the remote ds1
level, i.e. remote loopback of one of the channels.
This is only an approximation, but I think it should be enough to
let you move forward. There are some good books out on t1/SONET
that will explain all the gory channel bank or M13 vs M23 stuff,
there's a pretty good short form in the Larsecom T3SU manual, which
you might find on-line on their website.
George
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:16 EDT