HDTenEightyP/NetNews huggingface dataset:
From: sfrazier@norstan.com (Steven E Frazier)
Subject: NT1
Organization: Norstan Communications - Columbus, Ohio
Date: Fri, 8 Jan 1993 18:26:27 GMT

Thanks for the answers I got on the questions I had on routing and
bridging.

I thought I understood the ISDN piece, but I don't.  Ok if you have
a bridge from one of the vendors, then that bridge's RJ45 plugs into
a NT1?  I thought the RJ45 went directly to a telco RJ45.  Can someone
elborate on the single pair or is it two paris of wires coming in from
the Telco.  They wire it to a RJ45?  The customer then buys a NT1
(which is what?  what does it do) and plugs this NT1 into the telco
RJ45 and then you can plug in a bridge to the NT1?

If someone can explain this piece, I would appreciate it.

Thanks again.  I am getting there :)

Steve


-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
Newsgroups: comp.dcom.isdn
From: laubach@hpl.hp.com (Mark Laubach)
Subject: Re: ISDN - bridge - phone/TA
Date: Sun, 10 Jan 1993 05:40:36 GMT
Organization: Hewlett-Packard Laboratories Palo Alto,CA
X-Newsreader: TIN [version 1.1.4 PL6]

Superuser (sfrazier@norstan.com) wrote:
: If you had a NT-1 installed on your newly installed 2B+D line in your
: home and you decided that you wanted/needed a bridge to extend your
: TCP/IP connection from your office, you installed one of the available
: bridges.
: 
: Now the next question is, you need dialtone.....

Well, the solution we're using (Combinet CB200 ISDN Ethernet bridge) gets
the dialtone, I believe, off the D channel.  I ought to know more about
this but haven't taken the time to look into it in depth.  The box takes
care of doing all the dialing, so a phone is not needed to make a
connection to work.  2B+D goes into NT1-200 goes into CB200.

Hope this helps.

Mark

Newsgroups: comp.dcom.isdn,comp.protocols.ppp
From: ariel@world.std.com (Robert L Ullmann)
Subject: Re: dp2.2 on Interactive V3.2 & ISDN
Organization: The World in Boston
Date: Fri, 8 Jan 1993 21:37:24 GMT

Hi,

Ah, there are 3 (FR, PPP, X.25); and only X.25 is full-standard
in both Internet and ISO/CCITT. (The Internet standard has a revision
in process, at Proposed state, see RFC1356.) FR is close to the
same status. 

One of the reasons you don't hear too much about X.25 is that it is _done_,
it doesn't need debate over what the standard will look like when
it emerges; it is heere already. (;-)

Rob
--
Robert Ullmann		Ariel@World.STD.COM	+1 508 879 6994 x226
Quand Maigret poussa la porte du Tabac Fontaine, vers une heure et demie,
le patron du bar, qui venait de se lever, descendait lentement un escalier
en colimaon qui s'amorait dans l'arrire-salle. ... Arriv derrire le
comptoir, il repousa le garon d'un geste ngligent de la main, saisit
une bouteille de vin blanc, un verre, mlangea au vin de l'eau minrale et,
la tte renverse en arrire, se gargarisa.  -- Simenon

Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: V.42bis for a B Channel, was Re: V.42bis over V.120? (was Re: Can etc
Organization: Corporation for Open Systems
Date: Wed, 6 Jan 1993 14:50:59 GMT

In <5d64cf83.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu (Jim Rees) writes:

>In article <scott.726276501@labtam>, scott@labtam.labtam.oz.au (Scott Colwell) writes:

>  I believe that V.42bis ought to be extended to allow some more compression
>  algorithms to increase compression factors, rather than to decrease the
>  processing requirements.

>As I understand it, v.42bis already includes the ability for the two ends to
>negotiate the size of the string table, and therefore the storage
>requirements of the compression engine.  I would guess that the processing
>power required would also vary with string table size.  I believe most
>existing modems use an 11 bit table.

>  As far as compression over ISDN is concerned, it seems to me that the correct
>  place for compression is higher up the protocol stack.

>Agreed.  Since compression requires an error-free channel, it really can
>only go at transport layer or higher, if you want to move it above data
>link.  We thought about doing a separate LZW compression on each tcp
>connection, along with vj compression of the tcp/ip headers, but never
>implemented anything.  One nice thing about v.42bis is that it does a good
>job of getting out of the way when upper layers are doing compression.

Scott raises a good point, especially regarding images where it is
likely that JPEG or MPEG schemes would be used. In fact, in the
area of desktop video, we need some standard method such as MPEG
At TRIP'92 the attendees were quite interested in desktop video
applications, but it will have to be plug and play to suceed. I
need to know that whoever I call can interact with me regardless
of whose system they are using.

I was not aware of V.42bis' ability to 'get out of the way' but then
there is a heck of a lot I don't know about V.42bis and modems in
general (I just use them). The comment (Scott?) that we don't need
to proliferate standards is one I agree with if the existing ones
doe the job. 

Bob
Newsgroups: comp.dcom.isdn
From: dem@fnal.gov (David E. Martin)
Newsgroups: comp.dcom.isdn
Subject: Re: PPP on multiple B channels
Date: 4 Jan 1993 16:31:36 GMT
Organization: Fermi National Acclerator Laboratory, Batavia, IL, USA
Distribution: world
Reply-To: dem@fnal.gov
NNTP-Posting-Host: nhmpw2.fnal.gov

In article p00136@psilink.com, "Bob Larribeau" <p00136@psilink.com> writes:
>Is there any work going on to define how to support PPP on more than one 
>B channel or has this problem already been solved?  The most important 
>case is probably to support PPP on 2 B channels.
>
>		Bob Larribeau
>		San Francisco


You probably don't want PPP to know about the number of channels.  Why not use
something like BONDING (bandwidth-on-demand internetworking group).  Then present
the aggregate bandwidth to PPP?

David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: dem@hep.net



Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: 23B+D (PBX) & 2B+D (Home)
Organization: Corporation for Open Systems
Distribution: world 
Date: Mon, 11 Jan 1993 15:13:31 GMT

In <C0n63t.GBM@norstan.com> sfrazier@norstan.com (Superuser) writes:

>Would the following work?

>Install a 23B+D T1 into an ISDN compatible PBX from the local Telco.
>From the local telco install 23 2B+D to 23 individual homes.

>The pbx would supply the "dial tone", if you will, the phone number would
>be a DID on the PBX.  The individuals could wwork out of their home.  All
>23 people could make and receive calls at the same time due to a 1:1 ratio.

>If the above will work, then obvious, data to and from the homes should
>work as well.

>Anyone, please comment if the above would or wouldn't work.

For the PBX to "supply dialtone" the users would need to be on the
S reference point side of the PBX.

What you want could be accomplished by number translation at the
switch, i.e., 999-2765 is not really at the PBX but is at 9th Ave.

Abbreviated dialing translations could also take care of calling
between PBX users. Applies to either voice or data.


>Thanks.


>-- 
>Norstan Communications, Inc.        | Steven E. Frazier
>8101 N. High Street Suite 100       |---------------------------------------
>Columbus, OH   43235                | Local : sfrazier
>Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com

Bob.
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: ISDN & satellite telemetry
Organization: Corporation for Open Systems
Distribution: world	 
Date: Wed, 6 Jan 1993 14:45:58 GMT

In <1993Jan5.204611.7884@cs.tulane.edu> newcomb@pops.navo.navy.mil (Don Newcomb) writes:

>A common problem in Oceanography and other earth sciences is getting
>the data back from remote instrument packages. Telemetered data often
>flow through a variety strange routes on their way to the laboratory.
>I was intrigued to learn that Motorola's proposed Iridium satellite
>cellular telephone system includes ISDN capability in each subscriber
>unit.

>I was wondering if anyone knows of other direct-to-subscriber satellite
>communications systems that provide ISDN capability.
>--
>Donald R. Newcomb                * Views expressed are strictly those of the *
>Naval Oceanographic Office       * author. Mention of commercial products or *
>Stennis Space Center, MS 39522   * organizations constitutes no endorsement. *
>newcomb@navo.navy.mil            * Phone (601) 688-5998  

Well, most of the satellite companies had representatives at SG XI and
SG XVIII meetings I attended. It has always been considered that user
to network access to ISDN could be by satellite. Probably because its
awful tricky running drop wire out to an oil rig.

Bob.
From: Arthur@cswamp.apana.org.au (Arthur Marsh)
Newsgroups: comp.dcom.isdn
Distribution: world
Subject: Asynchronous TAs
Date: Wed, 06 Jan 1993 21:01:26 +1000

On Thu 24 Dec at 05:30 Fred R. Goldstein <goldstein@carafe.enet.dec.com> wrote
in <1992Dec24.053712.22719@nntpd.lkg.dec.com>:

 FRG> BTW (in response to KPH's comment), T-Link is a 
 FRG> Northern Telecom rate adaptation protocol.  Introduced 
 FRG> with the SL-1 Add-on Data Module in 1979 or so, it was 
 FRG> used on the DEC CPI-32 in 1982.  It's smarter than 
 FRG> V.110, though also bit-oriented (not HDLC like V.120).  

There are updates to CCITT V.110 and V.120 approved and shortly to be
published. I have yet to see them, but would be interested to know if they do
anything to spell out the maximum DTE rate. After all, a V.32bis modem with
V.42bis might be expected to support a 57.6 kbps DTE rate.

 * Origin: Camelot Swamp MJCNA, Hawthorndene, Sth Australia (8:7000/8)
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.isdn
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Date: 7 Jan 93 06:45:09 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <C0Gn8s.721@world.std.com>, ariel@world.std.com (Robert L Ullmann) writes:
> ...
> It takes a _lot_ of peak-power CPU to keep the output going at
> 64kpbs at a high compression ratio, even if the _average_ CPU
> is small.


Is it a big deal for an 8088 or even 68000 in a modem doing v.42bis?
What about a 1000 SPEC multiprocessor?

I assume it's somewhere in between, but where?  How many cycles per
byte output is "a _lot_"?  With familiar, various assumptions about the
character of the data stream, what are the average, median, and peak
cycles/byte for
    - v.42bis with the various dictionary sizes
    - splay trees
    - LZW
    - anything else

I guess the memory requirements for all reasonable compress schemes
are in the few KByte/data stream range.  Is that a good guess?


Citations for this stuff would be nice.


Vernon Schryver,  vjs@sgi.com
Xref: sparky comp.dcom.isdn:1119 comp.protocols.ppp:1058
From: rees@dabo.citi.umich.edu (Jim Rees)
Newsgroups: comp.dcom.isdn,comp.protocols.ppp
Subject: Re: dp2.2 on Interactive V3.2 & ISDN
Date: 9 Jan 1993 14:44:35 GMT
Organization: University of Michigan CITI
Distribution: world
Reply-To: Jim.Rees@umich.edu
NNTP-Posting-Host: dabo.citi.umich.edu

In article <C0KL1M.LuI@world.std.com>, ariel@world.std.com (Robert L Ullmann) writes:

  Ah, the standard myth. The problem was that a lot of X.25 implementations
  (the *OLD* Sunlink comes to mind) were really awful; they were usually
  "designed" to run at maybe 9.6K and do badly even at that.

I wasn't speaking of the implementation.  I was speaking of the protocol.
There is a basic mismatch between the tcp/ip architecture and the
x.25 architecture.  x.25 was invented before the concept of layered
protocols became fashionable, and it contains transport, network, and
data link layers all in one big rat's nest.  It does all sorts of things
like flow control that you don't necessarily want sitting under a proper
transport protocol like tcp.

  X.25 can blow the doors off of PPP when it comes to real interoperation
  and effective reliability.

I won't argue with that; however...

  If all you want is a freebie hack that might work
  most of the time, by all means use PPP.

There are good commercial implementations of ppp out there, Morningstar for
example (and given the unnecessary complexity of ppp, these people have my
respect).  And as you yourself pointed out, there are poor commercial
implementations of x.25.
Newsgroups: comp.dcom.isdn
From: jmccorm@a.cs.okstate.edu (MCCORMICK JOSHUA C)
Subject: Re: ISDN international tariffs
Organization: Oklahoma State University, Computer Science, Stillwater
Date: Mon, 4 Jan 93 16:02:08 GMT

AM> >With a good modem, one can get about 1500 cps on one of these
AM> >64 kbps PCM voice circuits.

AM>  AV>    1500 cps in one direction...
AM> 
AM> Well, V.32bis is supposed to be full duplex, but I haven't had
AM> too much luck with protocols that transfer files in both
AM> directions at the same time. Under good conditions with
AM> V.32bis/MNP 4 I've had 1700 cps one way on non-compressible data,
AM> but not on international calls.
 
Referring to the other person's reference of 1500cps in one
direction, he may be refering to an HST connect (US Robotics
proprietary standard) which provided 1650 (the newest version
around 1900) cps average with a v.42bis connect on already
compressed data. (Uncompressed data yeilding higher rates
even approaching 3000 cps!)
 
V.32bis is full duplex, and programs that make use of the bidirectional
aspect are becoming more common. 1650cps is around average for
already sending compressed data (with v.42bis). If the data in not
compressed, I have surpassed 3000 on text files with my Practical
Peripherals v.32bis/v.42bis modem.
 
For international calls, HST is rumored to be better than V.32bis,
but I don't believe that I've seen any hard tests proving it.

Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: Newbie Q
Organization: Corporation for Open Systems
Distribution: world 
Date: Tue, 5 Jan 1993 14:37:05 GMT

In <24677@galaxy.ucr.edu> rogue@ucrengr.ucr.edu (ed zeamba) writes:

>Ahhh.. if you can excuse an ignorant but enthusiactic student of
>dcom asking a dumb question... :)

>What exactly is ISDN?

>simple enough eh?

Hmm? A Canadian at UC Riverside?

To put ISDN in very simple terms, it does two basic things. Firstly,
it extends digital transmission right out to the user over the local
loop - in one interface (Basic Rate I/F or BRI), the user gets two
64 kbit/s lines. In the second interface (Primary Rate I/F or PRI),
the user gets 23 64 kbit/s lines or 30 64 kbit/s lines - depends
on the carrier system used.

Secondly, ISDN extends a common channel signaling system to the user.
Unlike POTS where once the necessary number of digits had been sent
to the switch, at which point the only signaling left was the switch-
hook, the ISDN ccs is always alive and much more powerful. In the
BRI, this signaling channel is 16 kbit/s wide, in the PRI it is 64
kbit/s wide.

A very simplified description to be sure, but think about the idea
that now you will have a powerful (in terms of protocol) access to
the intelligence available in the network. Almost anything you can
think of is possible. Oh, BTW, in the BRI all this runs over a
single copper pair, the PRI uses two pair or co-ax, depending on
the carrier system.

If I can answer any more questions, you can try e-mail to my site,
or if it is of general interest, pop them up here.

>-- 
>     /                                                                \
>@###I===============> "Know me as GORD of GREYHAWK..." <===============I###@ 

Bob [bob1@tango.cos.com]

>     \		                                                      /
>rogue@ucrengr.ucr.edu		UC Riverside -- home of the Guildsman
From: marc@aria.Ascend.COM (Marco S Hyman)
Newsgroups: comp.dcom.isdn
Subject: Re: PPP on multiple B channels
Date: 7 Jan 93 16:17:00 GMT
Organization: Ascend Communications, Alameda, CA

In article <2935351554.0.p00136@psilink.com> p00136@psilink.com (Bob Larribeau) writes:
 > >FROM:   David E. Martin <dem@fnal.gov>
 > >
 > >You probably don't want PPP to know about the number of channels.  Why
 > >not use something like BONDING (bandwidth-on-demand internetworking
							^^^^^^^^^^^^^^^

It's 'interoperability'

 > >group).  Then present the aggregate bandwidth to PPP?
 > 
 > What I am asking about is a standardized approach that will assure 
 > interoperability.  Using PPP over BONDING sounds like a fine approach.  
 > Is it being adopted as the standard approach by the IETF?

Expensive solution.  Forgetting PPP for a second, all you want to do is
send a packet on B1 then send a packet on B2.  I've been told that the
Combinet box does just this.

BONDING specifies interoperability requirements for inverse muxes.  IMUXs
have to worry about things like channel transpositions, relative delay
between channels in use, channelized/non-channelized interoperation, etc.
This typically takes a DSP or three plus support hardware.  All of this is
needed to present the user with what looks like an Nx56/64 kbit/s circuit.
It's not needed to switch packets.

IMUXs can add value, however.  Our box, for example, can look at the
flag/non-flag ratio and determine that more or less bandwidth is needed.
The box then adds or subtracts switched channels.

// marc
-- 
// work: marc@ascend.com          uunet!aria!marc
// home: marc@dumbcat.sf.ca.us    pacbell!dumbcat!marc
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.dcom.isdn
Subject: NT1 
Distribution: world
Date: Sat, 09 Jan 93 03:43:44 GMT
Organization: Crynwr Software

In article <C0JsK4.58s@norstan.com> sfrazier@norstan.com writes:

   I thought I understood the ISDN piece, but I don't.  Ok if you have
   a bridge from one of the vendors, then that bridge's RJ45 plugs into
   a NT1?  I thought the RJ45 went directly to a telco RJ45.  Can someone
   elborate on the single pair or is it two paris of wires coming in from
   the Telco.  They wire it to a RJ45?  The customer then buys a NT1
   (which is what?  what does it do) and plugs this NT1 into the telco
   RJ45 and then you can plug in a bridge to the NT1?

Okay, there are two ISDN interfaces in the US, S/T and U.  The NT1
converts the two-wire U into the four-wire S/T.  In other countries,
the NT1 is the property of the PTT, so they only have S/T.

The NT1 does all the signal processing necessary to separate the
transmit and receive signals, and to correct for the icky local loop.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
Newsgroups: comp.dcom.isdn
From: sfrazier@norstan.com (Superuser)
Subject: ISDN TCP/IP Routers
Organization: Norstan Communications - Columbus, Ohio
Date: Fri, 8 Jan 1993 00:04:37 GMT

If you have an ISDN bridge such as the Combinet or the DigiBoard and you
wanted to place one on your existing office's Class C network, I understand
that you would assign an IP address to the Bridge.  This would allow you
to configure it from your existing network.

Now if you wanted to place one in another office, would you have to 
get another Class C for that bridge and network there, or could you
subnet off your existing Class C's office network?  I am a little
confused on how the IP addresses would work.  I understand the
ISDN side and the bearer channels.

Could someone elborate on two examples for the net (or myself)?

(1) At the main office you have one class C ethernet running and you
    want to add a bridge at the office.  You want to add another
    bridge across town in another office.  Both offices can have ISDN
    both offices have a bridge, 

     [unix]-------[unix]-------[bridge]----[unix] 192.91.101.10.0-255
                                  |
                                  | 
                                  | ISDN
                                  |
                                  |
     [unix]-----[unix]--------[bridge]-----[unix]----[unix]  same class C
                                                              or another class
                                                              C ????

(2) At the main office you have one class C ethernet running and you
    want to add a bridge at home.  

     [unix]-------[unix]-------[bridge]----[unix] 192.91.101.10.0-255
                                  |
                                  | 
                                  | ISDN
                                  |
                                  |
                               [bridge]----- [unix]  same class c or
                                                     a new class c for
                                                     one unix box?


I am just trying to understand if you need to get seperate class C's
if you are bridging to another location.

Thanks in advance.

Steve








-- 
Norstan Communications, Inc.        | Steven E. Frazier
8101 N. High Street Suite 100       |---------------------------------------
Columbus, OH   43235                | Local : sfrazier
Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com
From: dem@fnal.gov (David E. Martin)
Newsgroups: comp.dcom.isdn
Subject: Re: Terminal Adapters
Date: 4 Jan 1993 16:26:36 GMT
Organization: Fermi National Acclerator Laboratory, Batavia, IL, USA
Distribution: world
Reply-To: dem@fnal.gov
NNTP-Posting-Host: nhmpw2.fnal.gov

In article 184724@pyramid.pyramid.com, lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
...
>    Why not replace the entire kludge with the Combinet ISDN "smart"
>    bridges?    
...
>
>This unit uses an ISDN BRI.  It has dynamic compression/decompression
>of data for increased thruput. 
... 

I have been using the Combinet bridge for some time and it does not have
data compression.  Do you have a different model?

David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: dem@hep.net


Newsgroups: comp.dcom.isdn
From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: University of Tokyo / Object Technology International
Date: Tue, 5 Jan 1993 17:08:06 GMT
X-Bytes: 1122

In article <bob1.726244213@cos> bob1@cos.com (Bob Blackshaw) writes:

 >In their demo at TRIP'92, France Telecom showed me a compression
 >algorithm (or at least the effects of one) over ISDN. When I asked
 >if it was V.42bis, they said no. According to the person I was
 >speaking with, they found V.42bis too processor intensive for a
 >64 kbit/s line and it actually slowed throughput. They claimed to
 >be achieving throughput in excess of 110 kbit/s on a 64 kbit/s
 >line. I didn't have a stopwatch with me, but it certainly looked
 >impressive. Hopefully, they will submit it to CCITT.

I am not sure that I understand the compression problem.  There are
several schemes available that do on the fly compression on data to
disk.  The data rates are significantly higher and they actually make
the disk interaction faster.  That is, the amount of time saved
reading bytes is greater than the extra required to de/compress.
Given that 64kbits/s is at least a couple orders of magnitude less, I
would have thought that this would not be an issue.  How are the cases
different?

--
ato de, |m        -- Death by stereo!