HDTenEightyP/NetNews huggingface dataset:
From: rberger@nic.cerf.net (Robert J. Berger)
Newsgroups: comp.dcom.isdn
Subject: ISDN to Internet Gateways?
Date: 27 Jan 1993 02:20:52 GMT
Organization: Uranix Media Productions
NNTP-Posting-Host: nic.cerf.net

Is there a commercial service yet that offers ISDN dialup into the Internet?

Thanks,


-- 
Robert J. Berger - Multimedia SW & Content Creator
935 College Avenue Menlo Park, CA 94025 
Voice: 415-327-6038 FAX: 415-327-6416
rberger@cerf.net (formerly berger@sfc.sony.com)
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: BONDING and T1 Letter Ballot 317
Organization: Corporation for Open Systems
Distribution: world 
Date: Thu, 21 Jan 1993 14:16:11 GMT

In <1993Jan20.132319.10075W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

>In article <1993Jan19.135401.21097@cbfsb.cb.att.com>, deej@cbnewsf.cb.att.com 
>(david.g.lewis) writes:

>> [...] There's a feeling among some in the industry, however,
>>that (a) for a BRI, 2B is a useful bandwidth that is not supported by any H
>>channel, and (b) limiting to 384 and 1536 kb/s is insufficiently flexible
>>for user applications, and allowing NxDS0 where N is any integer from 2 to
>>24 or 30/31 (on PRI, at least) is a useful and necessary capability.

>In the bluebooks, there IS a 2*64 kbit option (table 4-6 and 4-8/Q.931). 
>Yes, I know that there is a difference between 1*128 and 2*64, but for many
>purposes the existing standard would be good enough, and the justification
>for inventing a different wheel rather weak.

>Disclaimer: I do not know anything about the '92 edition, so things may
>have changed there. Further, I am not sufficiently deep into the lower 
>layers to see all the consequences of the "Restricted Differential Time 
>Delay" (which allows the two 64 kbit streams to be out of synchronization 
>by a certain amount).

I'm always tempted to call this R2D2 :-), however, not being in the
meetings (I got out of that back in 87), a look at the S/T Layer 1
frame structure leads me to believe that the ~50 ms factor in RDTD
is simply a result of the separation of the B-channel octets in
each frame. You will see that the greatest separation occurs between
the first pair of B-channel octets and amounts to 5 bits. Now a 48
bit frame at 125 ms approximates a bit time of 5 ms, ergo 5x5=25.
Given a frame at either end of any connection 2x25=50. At least
that's how I believe it works.

Now, whatever type of state machine you are using at layer 2 should
be able to accomodate this slight out of sync condition with some
form of simple buffering (or elastic store, if you prefer that term).
If I'm wrong will someone who was at the meetings please correct me.

>Yet, many wheels have been invented simply because the inventor overlooked
>existing solutions. Basing a 2B solution on existing standards may be a
>good idea. I don't think it is essential to provide 3B, 4B, 5B,...29B -
>after all, we manage with modem speeds in doubling steps, and with TDM
>channels in quadrupling steps (in Europe - US is more irregular), with
>noone claiming that eg. a 7200 baud modem standard would "increase
>flexibility", now that we got 4800 and 9600.

Also, this thread seems to have overlooked the H10 rate here in NA.
H10 allows use of 22 channels just in case you only have a single
PRI. If you used H11 on a single PRI you would kill your D-channel
and would then be in a bit of trouble.

Glad to hear you are a convert.

Bob.

Newsgroups: comp.dcom.isdn,comp.protocols.nfs
From: jbvb@vax.ftp.com  (James B. VanBokkelen)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Nntp-Software: PC/TCP NNTP
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., North Andover, Massachusetts
Date: Mon, 25 Jan 1993 17:12:49

In article <v61am5o@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:

    dcarr@gandalf.ca (Dave Carr) writes:
    | Try running PC/TCP over a 64 Kbps link and you'll see what I mean.  The
    | PC/TCP timers are not dynamic, and timeouts will occur.
    
    The fact that *one* ancient implementation of TCP is broken does not
    mean that all TCPs are broken. All modern TCPs have "dynamic" timers.
    
Perhaps you have a different definition of "dynamic" than I do.
PC/TCP's TCP retransmit timeout is dynamic, you can see it change
with the "INET TCP" command.  This isn't really the forum to throw
rocks at random TCPs, but I don't think any of the 4bsd derivatives
have moved out of their glass houses yet....

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

Xref: sparky comp.dcom.isdn:1202 comp.protocols.nfs:3192
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.isdn,comp.protocols.nfs
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Date: 22 Jan 93 00:47:39 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

dcarr@gandalf.ca (Dave Carr) writes:
+---------------
| There isn't that much difference in performance between a bridge and a
| router in terms of forwarding performance.  The big difference is the
| 100's of Kbytes of code to support the various stacks.
+---------------

You don't need 100's (or even 10's) of KB of code to route IP.
Look at any of the several PC-based routers (KA9Q, PCroute, etc.).

+---------------
| Try running PC/TCP over a 64 Kbps link and you'll see what I mean.  The
| PC/TCP timers are not dynamic, and timeouts will occur.
+---------------

The fact that *one* ancient implementation of TCP is broken does not
mean that all TCPs are broken. All modern TCPs have "dynamic" timers.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.dcom.isdn
Subject: Re: isdn "supermodem"
Date: 25 Jan 1993 20:14:11 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

Dave Carr (dcarr@gandalf.ca) wrote:

: > customers      | POTS |          C.O.        | ISDN link |  my house

: >  end user modem ------ modem --|-------------|
: >  end user modem ------ modem --|             |
: >  end user modem ------ modem --| multiplexer |         +---------------+
: >  end user modem ------ modem --|             |=========| my BBS server |
: >  end user modem ------ modem --|             |         +---------------+
: >  end user modem ------ modem --|-------------|

The "multiplexer" in this picture is an ordinary terminal server.  
Your BBS server has a point to point ISDN link that's running TCP/IP.
The "C.O." is an Internet service provider who has rented you the
use of their modems for incoming calls, so that when you hit their
dialins you can not only say "msen" but also perhaps "mybbs".  You
have no modems on site, just an ISDN line, and you're reachable only
from the Internet.

Could be done right now - the problem is that asking someone else to
own and operate your modems is more eepensive than doing them yourself;
that most X.25 service providers with big banks of modems (Sprint,
Compuserve) are in the dark about IP; and that we still don't have
the point-to-point ISDN link down pat.


  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB

Newsgroups: comp.dcom.isdn
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 28 Jan 1993 05:02:19 GMT

dcarr@gandalf.ca (Dave Carr) writes:
+---------------
| Bridging can be done transparently to the protocol, and thus one chunk
| of code works on all protocols.  Routing requires separate code for
| each protocol.  
+---------------

Actually, while this is mostly true, even bridging requires requires
separate code for some protocols depending on the media being bridged.

Example #1, FDDI to Ethernet: All protocols encapsulated with the
802.2/LLC/SNAP/OUI=0/ethertype method are converted to D/I/X Ethernet
encapsulation with the same "ethertype" *EXCEPT* Appletalk Phase 2,
which insists on using the 802.3/LLC/SNAP/OUI=0/ethertype encapsulation.

Example #2, 802.5 Token Ring to FDDI: The ARP protocol must have the 48-bit
hardware MAC addresses *inside* the ARP packet in the ar_sha and ar_tha fields
(that is, *above* the MAC layer) bit-flipped, since on FDDI (as on every MAC
layer except 802.5) those fields are carried in "canonical" order, but on
802.5 Token Ring they are carried in 802.5 bit-order. [Note: On FDDI, the
addresses in the FDDI *MAC* layer are carried in 802.5 order, but not the
ARP ar_{s,t}ha fields.]

I'm sure someone can provide some examples of protocol-sensitive XXX-to-ISDN
bridging (if not today, then "soon")...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: peter@micromuse.co.uk (Peter Galbavy)
Newsgroups: comp.dcom.isdn
Subject: Re: isdn "supermodem"
Date: 27 Jan 93 13:43:53 GMT
Reply-To: peter@micromuse.co.uk
Organization: MicroMuse Ltd, London

In article 264@indyvax.iupui.edu, imhw400@indyvax.iupui.edu () writes:
>                             Since your end users seem to be async. terminal
>types, put a PAD there as well.  {Sound of hundreds of readers making signs
>against the Evil Eye.}

... No please not that. Here take my children instead...

>When your customers cut over to ISDN, the modems and the PAD are bypassed but
>the PH is still there.  The customers supply their own PADs.  {Chanting becomes
>audible.}

What sort of holy symols do I need. Last time I used a matchstick and 2CC's of
mouseblood (TP fans should be able to explain...). Perhaps this should be x-posted
to alt.witchcraft ?

double :-)

---
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk
Newsgroups: comp.dcom.isdn
From: cstorry@gandalf.ca (Chuck Storry)
Subject: Re: BONDING and T1 Letter Ballot
Keywords: BONDING,ISDN
Organization: Gandalf Data Ltd.
Date: Tue, 26 Jan 1993 16:42:55 GMT

In <Kevin.Kershaw.4@StPaul.NCR.COM> Kevin.Kershaw@StPaul.NCR.COM (Kevin Kershaw  ) writes:


>Thanks to all who respoded to my inquiry on BONDING and T1 Multi-
>rate capability.  Your information has been very helpful.  
>As a follow on issue, I would be interested in obtaining more
>information on the BONDING protocols.  I am currently supervising
>a development that provides both BRI and PRI support for devices
>attached to our line of communications processors.  We have
>implemented a proprietary end-to-end protocol between our own
>devices that allows multiple B-channels to be brought into
>service to increase the end-to-end bandwidth.  This capability is
>dynamic (channels are brought into and out of service as needed)
>and can span channels on combinations of BRI and PRI interfaces. 
>This product was designed almost 2 years ago so the BONDING work
>was unknown to us at that time.  I would like examine whether it
>makes sense for us to move to BONDING in future releases. Does
>anyone know where I might obtain the specs for the BONDING
>procedures?

There are other "standards" in addition to BONDING to consider (or perhaps
not). They include CCITT H.221 and I belive that Australia has one.

I heard a rumour that CCITT rejected the BONDING spec as the basis for
inverse muxing in favour of a revised/modified H.221. Anyone know the 
details or validity on this ?



>The big difference with ISDN on this point is that you are going 
>to pay your service provider for each additional channel you
>bring on line.  If you are running 2 B already (128K) and another
>64K on line will cover your needs, why pay for another 128K?

This brings me to BONDING mode 3. Do we really need to add bandwidth on 
8khz increments ? If you add another B channel why not give all 64K to 
the user ?

(For those not in the know BONDING consists of 4 modes:
mode 0 - inband negotiation (no B channel aggregation)
mode 1 - inband negotiation , channel equalization and subsequent aggregation
         (but no monitoring for loss of sync and no end-end com channel)
mode 2 - mode 1 and overhead framing to determine synchronization status
         and an end-end communication channel in order to dynamically
         add and remove channels (and maintenance : loopback, etc)
mode 3 - as per mode 2 but bnadwidth is added in 8k increments rather than 
         "B" channel (56/64k) increments.

Note: this is my interpretation of the Spec and is not an officially
sanctioned synopsis of BONDING.

>Kevin Kershaw                              DAMN IT'S COLD OUT......
>NCR Network Products Division
>St. Paul, MN.
-- 
Chuck Storry, Principal Designer      CAnet: cstorry@gandalf.ca
Gandalf Data Ltd.                     Voice: (613) 723-6500
130 Colonnade Rd So, Nepean, Ontario  Fax: (613) 226-1717
Canada  K2E 7M4
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: BONDING and T1 Letter Ballot 317
Organization: AT&T
Date: Fri, 22 Jan 1993 14:01:54 GMT

In article <bob1.727625771@cos> bob1@cos.com (Bob Blackshaw) writes:
>In <1993Jan20.132319.10075W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>
>Also, this thread seems to have overlooked the H10 rate here in NA.
>H10 allows use of 22 channels just in case you only have a single
>PRI. If you used H11 on a single PRI you would kill your D-channel
>and would then be in a bit of trouble.

H10 is 23*B (1472kb/s), not 22; additionally, in the current draft addendum
to T1.607 (American Standard for ISDN access signaling - Q.931 equivalent)
the H10 codepoint is deleted.

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
Newsgroups: comp.dcom.isdn
From: bcapps@atlastele.com (Brent Capps)
Subject: Re: 23B+D (PBX) & 2B+D (Home)
Organization: Atlas Telecom Inc.
Date: Fri, 15 Jan 1993 17:05:10 GMT

In article <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.

You wouldn't want to make the T1 23B+D to do this -- too many muxing
problems.  Instead, you'd want to order the T1 to run ESF/B8ZS, DACS 
out the DS0s to _24_ residences as leased lines and drive each DS0 
as a BRI OPX on the PBX.  
-- 
Brent Capps                          | 
bcapps@agora.rain.com (gay stuff)    | Quis corriget correctores ipsos?
bcapps@atlastele.com (telecom stuff) |
Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: Re: ISDN/analog interfacing
Organization: Consultant
Date: Wed, 27 Jan 1993 03:52:57 GMT
X-Mailer: PSILink-DOS (3.3)

>DATE:   Tue, 26 Jan 1993 06:23:11 GMT
>FROM:   Jeff McAffer <jeff@is.s.u-tokyo.ac.jp>
>
>I have seen some stuff on ISDN serial TAs which have analog ports on
>them.  If I want to dial *into* that analog port, how is that
>accomplished?  I assume that the analog port has some sort of
>subaddress but how do I specify that at the calling end?  Is the
>analog nature of the incoming call detected automatically by the TA?
>

The TA receiving the call can differentiate a voice call from a data 
call using the Bearer Service Information Element.  When the Set Up 
Message is received it uses the Bearer Service Information Element to 
determine whether the call is voice or data.  The TA can then route the 
bit stream to the right port.

It is not a problem at the calling end.  You specify by making a voice 
call or data call.

		Bob Larribeau
		San Francisco

hito ga oboieru aida ni obieraremasu.
Newsgroups: comp.dcom.isdn
From: Mboyd@mitre.org
Subject: HELP!!
Organization: The MITRE Corporation, McLean VA 22102
Date: Wed, 27 Jan 1993 14:07:52 GMT

I was just assigned the responsibility to take over the task of developing
an ISDN testbed to evaluate ISDN capable equipment and applications.  I
need some help here to bring me up to speed fast.  What should I read?
Also what are some of the key questions I should ask to get a clear picture
of the capabilities my company wants this testbed to have?  About all I
know at this point is that they plan to use a Teleos ISDN switch simulator.
 
Any help would be greatly appreciated!!
 
Martin
From: peter@micromuse.co.uk (Peter Galbavy)
Newsgroups: comp.dcom.isdn
Subject: Re: Low cost ether/isdn brouters (was PC-NFS
Date: 27 Jan 93 13:49:22 GMT
Reply-To: peter@micromuse.co.uk
Organization: MicroMuse Ltd, London

In article 8jr@nic.near.net, jcurran@nic.near.net (John Curran) writes:
>I concur.  While there might be many unique applications that will require
>ISDN speaking remote bridges, one existing market (internet service providers)
>will be looking for low-end BRI router with demand-dial, filtering, and 
>remote maintenance capabilities.  Given the maximum link speed, performance
>will not be a distinguishing capability, and that means that low-cost will 
>be a major feature of the market winner.

Stands on soapbox:

Try telling this to *anyone* in the UK. We have enough problems with the
greedy modem manufacturers already. A V32 modem for #500 ($800) ? Sigh.

People like Spider are touting an ISDN router box that seems to work well
according to users, but take a look at the (at least) #3000 ($5000) price
tag. sigh again. Most comms hasrdware manufacturers seem to like the idea
of selling ISDN as a leased line back up solution, since (the reasoning
must be) if you can afford a leased line, you can afford the sick prices
they are charging.

I can`t wait for the manufacturers whinging about getting approval and development
costs etc...

Climbs off soapbox...
---
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk
Xref: sparky comp.dcom.isdn:1201 comp.protocols.nfs:3191
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.isdn,comp.protocols.nfs
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Date: 22 Jan 93 00:37:38 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

dcarr@gandalf.ca (Dave Carr) writes:
+---------------
| Interesting.  Could you tell me more.  With ISDN, we are basically talking
| about a point-to-point link.  Our view is with the right software mods, you
| can get the desired performance out of a bridge.  The trickiest part is the
| handling of multicast and broadcast.  If we can eliminate these packets
| without doing the entire routing function, do we have what you need?
+---------------

It's not the broadcasts/multicasts that hurt so much, but the total lack of
filtering ("learning") on your low-end product. As we told your sales folk
when they visited here, anybody who has an Ethernet at home probably has
more than one device on that Ethernet, which makes a bridge that doesn't
do filtering worse than useless!

Actually, what I'd prefer even more is a cheap *router*, not a bridge. That
would completely avoid the questions of "learning"/filtering, broadcast,
and multicast. And since we all *know* somebody could make a cheap router
with a PC, an Ethernet card, and an ISDN card...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
Newsgroups: comp.dcom.isdn
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Organization: Gandalf Data Ltd.
Distribution: na
Date: Mon, 25 Jan 1993 14:36:03 GMT

In <C18qsB.1DB@wsrcc.com> wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes:

>Not to start a war or anything, but I'm curious why do folks build
>bridges as opposed to routers.  Is it to save the cost of writing the
>code to do the TCP/IP hacking or is it that they would need much more
>hardware to support the computional horsepower needed to unravel the
>upper level protocol and then wrap the data-packet back up?

There seems to be a universal myth that routing requires significantly
more horsepower than bridging.  Actually, the real-time packet forwarding
is about the same.

Bridging can be done transparently to the protocol, and thus one chunk
of code works on all protocols.  Routing requires separate code for
each protocol.  
Newsgroups: comp.dcom.isdn
From: nisimura@sran233.sra.co.jp (Tohru Nishimura)
Subject: Re: isdn "supermodem"
Organization: Software Research Associates, Inc., Japan
	<1993Jan23.215546.8466@xenitec.on.ca>
Date: Sun, 24 Jan 1993 07:16:03 GMT

In article <1993Jan22.160035.7443@sifon.cc.mcgill.ca>, rob@polestar.facl.mcgill.ca (Robert Macfarlane) writes:

> Here's an arrangment I would like to see:
>
>  customers      | POTS |          C.O.        | ISDN link |  my house
>
>   end user modem ------ modem --|-------------|
>   end user modem ------ modem --|             |
>   end user modem ------ modem --| multiplexer |         +---------------+
>   end user modem ------ modem --|             |=========| my BBS server |
>   end user modem ------ modem --|             |         +---------------+
>   end user modem ------ modem --|-------------|

Although it is not the product what Robert Macfarlane wants, there is a
product utilises an ISDN line as a flexible multiplexed line.

The box is manufactured by NEC, which provides various convensional
interfaces with plug-in cards upto 16 slot.  There are 5 type cards;
2 port analog telphony card, 2 port X.21 card, 2 port V.35 card, 2 port
RS-232 card, 2 port RS-449 card.  You can combine any cards in one box.
Unfortunately there is no "super modem" card fit in the box, yet.

      PRI ISDN  +----------------------+
		|                      |-- various interfaces
    ===========>| multiplexing PRI TA  |-- phones, V.35, X.21, RS.232
		|                      |-- RS-449
		+----------------------+

This TA are able to provide independant 23 B channels (because Japanese
PRI servies is 23B+1D), or serval H0 channels, or one H10 channel.

Most important feature is this box is able to provide very flexible use
of one ISDN line, such as on-demand "line bonding" for H0 or H11 call,
one (and/or serval) line numbers for a set of multiple equipments,
explicit equipment determinatating with "subaddress", and so on.
In some sense, this box is similar to flexible full funcational PBX.

I do not know whether this NEC ISDN TA is available in North America area,
however, TANDEM Computer System sells "TANDEM block" coloured version as
their product at least in Japan.

Tohru Nishimura
Software Reseach Associates, Inc. Tokyo Japan

Have you ever seen "ISDN digital public telephone" on the street?  It has 1
RJ-11 analog port and 1 RJ-45 ISDN digital port as well as oridinal public
telephone.  Although there is no ISDN card for Note PCs (yet), I have ever
used it with ISDN/IP card equiped SONY UNIX laptop.