From: lgm@ulysses.att.com (L. G. McKnight)
Newsgroups: comp.dcom.isdn
Subject: Re: Network Connections over ISDN
Date: 16 Aug 92 01:44:11 GMT
Organization: AT&T Bell Labs, Murray Hill, NJ, USA

There are enough misconceptions in this article to warrant a detailed
reply:

>Again, the 16 kbit/s capacity of the D-channel is TOTAL including all
>traffic control signaling between CO and terminal. This radically
>reduces the available bandwidth for user-user net throughput. Add to
>this that the CO is at full liberty to impose flow control on user-user
>D-channels and you definitely have a real-life capacity of much less
>than what I'd accept for X work.

Except for call setup and teardown the amount of signaling data on the
BRI D_Channel is actually quite small.  Spontaneous traffic from the
switch -- an RR-and-reply "heartbeat" every 30 seconds and a TEI check
at about 4 minute intervals -- is so spread out that it hardly constitutes
a load.  Call setup and teardown is under user control.  If you are not
setting up calls (or tearing them down) there is virtually no load on the
D-channel.  Using a D-channel monitor on a BRI line shows that 16 kbit/sec
is almost always available for use.  The overhead in the LAP-D packets
(7 bytes per packet plus bit stuffing) is probably the most important
reason why the BRI D-channel can't routinely carry the full 16 kbits/src.
If your packet- assembler-disassembler (PAD) is inefficient you will end
up with lots of small packets and lots of packet overhead.
I have not tried to use X -windows over ISDN.  Notes on the network
indicate that X-windows works surprisingly well over a 64 kbit/sec
B-channel.  I assume that this means that the D-channel would be too slow.

>			Maybe it works now, when few others
>have ISDN, but there's definitely a risk of this going away when the
>CO's CPU becomes loaded and activates the flow-control.

The load on the packet switching network will certainly affect throughput.
If everybody wants to download a huge file at once, then the network will
slow down the data flow.  Our packet switch is lightly loaded so I have
no experience with switch congestion.

>As for 19.2, that's not ever available on the D-channel in 2B+D, not
>even in theory.

If we assume that "19.2" refers to the baud rate for an RS-232
connection -- which is almost certainly the case -- then 19.2 is, in
fact, available over the 16 kbit/sec D-channel.  The RS-232 signal
includes a start and a stop bit for each character so there are 10 bits
per asynchronous ascii character.  The D-channel carries only the 8 data
bits so an asynchronous 19.2 kbaud signal can be carried in 15.36
kbits/sec without compression.  Of course there is the LAP-D packet
overhead (which includes bit stuffing and depends on the packet size)
and the possibility of switch congestion and D-channel traffic so you
may get less than the full 19.2 kbaud data rate.  But you ought to
work at 19.2 kbaud because, if your packets are at all efficiently
packaged, you could expect little or no time between characters from
a TA operating at 19.2 kbaud reading data from the D-channel.

>I'm more than just a little annoyed with how the marketing crowd make
>broad statements about the D-channel capacity being 16 kbit/s without
>ever mentioning how much of it is CONSTANTLY used by the traffic
>overhead. The D-channel's primary function is to provide a signaling
>path between the terminal(s) and CO. There exist signaling elements
>for user-user communication but they are (at the best) of secondary
>priority to the CO. Not that I dislike the idea of using the D-channel
>for user-user data transfer, far from it, but it should be made
>perfectly clear that this is not a high-speed/volume service.

As I mentioned above, reference to a protocol analyzer will show that
(except for call setup and teardown) there is almost no traffic on the 
D-channel.  Check your packet assembler-disassembler to be sure that
it is packaging data in large packets.  If your PAD protocol is OK
then you must have a horrendous congestion problem on your network.

> The CO's primary function today is to transfer phone calls (audio). A
>few subscribers have ISDN and get their calls routed direct into the
>digital channels, others have analog lines and go through codecs at the
>CO first. The CO normally assumes that the data on the channel is
>PCM-coded audio and does not interfere with it except to translate
>u-law<->A-law in the case of international calls.

The CO's only function is to switch circuits.  For a digital switch
it is immaterial whether the circuits are voice or data because
all the circuits are treated as data.  Virtually all switches in the U.S.
long distance networks are digital and many Local Exchange Carrier (LEC)
switches are digital.  Almost all transmission lines are digital in
the United States.  If the Individual Subscriber Line Unit (ISLU)
in the LEC switch is an analog unit then the ISLU converts outgoing data
to analog and puts it out on the line.  Incoming analog voltages are
converted to (mu-law) data in the ISLU and routed through the switch
along the call circuit path.  For ISDN lines the data is sent out on the
line in the proper time slot without conversion.  Incoming data is
taken from the relevant time slot and routed through the switch --
to the proper circuit or virtual circuit depending on the call --
without converting the data.
It seems strange to think that an ISDN line which needs no analog-
to-digital (AtoD) conversion and does not have to supply ringing
voltage should be more expensive than a plain old telephone service
(POTS) line but that is the way that volume affects cost in our
economic system.

>						The ISDN call
>designators that identify the call type as "datacomm" are actually
>primarily to prevent the CO from jumbling the data by converting it (or
>passing it through an analog intermediate line).

The messages between the switch and the CPE are to see what services are
being requested and to check to see if the service is authorized i.e.
paid for.  ISDN allows each user to request the the type of service that
is desired.  The switch is responsible for obtaining the service, setting
up the circuit (or the virtual circuit), transmitting the data and billing
the user.  If it can't furnish the service then it rejects the call.  Of
course the customer premises equipment (CPE) at the receiving end can also
reject the call.

>					In a future scenario
>where datacomm is a larger part of the CO's business than it is today
>(remember: modems create audio sound streams, so today ALL non-ISDN
>calls are "audio") it may become interesting for them to provide more
>and better datacomm functionality.

As I said above, almost all calls in the U.S. are transmitted digitally
and there is lots of data on the network at speeds between 2.4kbits/sec
and 44 Mbits/sec.  Not to mention modem based voice band data (VBD).
Data on the network differs from voice in that it is not routed through
echo cancelers.  Otherwise it's all just data.  Data (which does not have
to go through echo cancelers) should not cost more to transmit than voice
(which does).  Packet switched networks don't have echo cancelers.

>The D-channel<->B-channel multiplexing as described is entirely within
>the reach of today's technology but I don't know that it's been
>implemented in the CO as such.

A call can be set up to route data to a packet switched network by any
number of routes.   Currently our CO switch routes D-channel data to
the packet handler section of the switch.  Higher data rates are
more economically sent as circuit switched data so our switch does
not have a link from the B-channel to the packet switched network.

>		The easy way is to hook up an external
>computer (say, a Sun SS10 with the ISDN chipset) and let it do the
>routing. Having the CO do it sounds extravagant to me.

The CO has to do the routing for every call through the telephone
network.  The cost is not "extravagant" -- after all the switch
does the routing for voice calls all the time.  The decision
as to whether a call should be circuit switched or packet switched
is up to the user.

>Then vjs@rhyolite.wpd.sgi.com (Vernon Schryver) says:
>
>>How much will that cost?  Will it be billed by the packet?  At rates
>>as outrageous as D-channel?
>
>The D-channel rates may seem outrageous to you but I assure you they
>are motivated by the exceptionally high costs D-channel connections
>cause in the CO. If the charges seem steep then I suggest you look at
>the alternatives, such as B-channel connections.

The rates for telephone services in the U.S. are too complex to
discuss here.  But certainly B-channel connections are not expensive --
as every modem user knows.  Sending data over B-channels is no more
expensive than sending VBD using a modem.  D-channel data should be cheaper
for bursty data over long distances.  If D-channel data is not cheaper
then data will be sent circuit switched over the B-channel.

>						Routing volume
>communication through the D-channels will call for a complete re-design
>of the CO's internal logic and while I'm sure this will eventually come
>about I'm equally sure it will take quite a while (and be QUITE
>costly). Until then we're stuck in a situation where too much D-channel
>volume will choke the CO and the telco will try to prevent this by
>charging heavily for it.

As I said above, all the long distance switches in the U.S. are digital
and digital switches are gradually relacing analog switches in the LEC's.
Digital switches are by their very nature designed to handle data.
However the telephone companies must make the investment in hardware
and software to handle ISDN.  If there are only a few users to bear
the cost then ISDN will be expensive.  But there is nothing intrinsic
in ISDN to make the service more expensive than the POTS service we
have now.

Lee McKnight
AT&T Bell Laboratories
Murray Hill, New Jersey, 07974
lgm@ulysses.att.com