dp2.2 on Interactive V3.2 & ISDN

dp2.2 on Interactive V3.2 & ISDN

Post by Gratien D'hae » Fri, 08 Jan 1993 18:29:05



Dear ppp-ers,

I am following the comp.dcom.isdn and comp.protocols.ppp newsgroups for a
while now. It seems to me that some people do actually use ISDN instead of
a common phone line + modems.

Could someone tell me how a  working configuration with ISDN looks like
(ISDN+TA+modem or ISDN-card plugged in a PC?). Personally, I would like to
use dp2.2, for its automatic dialup facilities and breakdown in
idle times.

In the first case (ISDN+TA+modem), it is probably rather easy to
configure dp2.2 to work with ISDN (just has to treat it as a modem?).

In the second case (ISDN card in PC), it seems to
me that there are parts missing in the dp daemon (to make a call via
the ISDN card).

Can anyone comment on this? Is it feasible to expand the amount of
keywords in the configuration file for dp (and build the knowledge to make
calls through the ISDN card into the dp daemon)?

Is their anybody using dp2.2 on an PC with Interactive UNIX V3.2?
Thanks/Gratien
--
  _______               Gratien D'haese    Switching Systems Division  se121
  \     /Alcatel                          F. Wellesplein 1, B-2018 Antwerpen


 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Tohru Nishimu » Sat, 09 Jan 1993 11:01:36



Quote:> Dear ppp-ers,

> I am following the comp.dcom.isdn and comp.protocols.ppp newsgroups for a
> while now. It seems to me that some people do actually use ISDN instead of
> a common phone line + modems.

> Could someone tell me how a  working configuration with ISDN looks like
> (ISDN+TA+modem or ISDN-card plugged in a PC?).

We have been ISDN customer over past two years, and using ISDN/IP links
for daily company work.  There are many many ISDN products in Japan.
Here is a product list of what comp.protocol.ppp/comp.dcom.isdn people
would like;

        ISDN bridge
        ISDN router
        integrated ISDN card for UNIX WS makes WS an ISDN/IP router
        integrated ISDN card for PC gives tranparent 64K sync link to PC
        ISDN TA with RS232C interfaces or V.35/RS.449 interfaces
        etc, ...

Unfortunately, there is interoperability problem between implementations,
as usual.  For example, different brand of integrated ISDN/IP cards would
not talk each other.  No surprise, please....

Tohru Nishimura
Software Research Associates, Inc. Tokyo Japan


 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Jim Re » Sun, 10 Jan 1993 01:20:31


  Unfortunately, there is interoperability problem between implementations,
  as usual.  For example, different brand of integrated ISDN/IP cards would
  not talk each other.  No surprise, please....

There are two emerging "standards" for ip over isdn.  One is rfc 1294 frame
relay encapsulation, the other is ppp.  An rfc 1294 ip frame looks like
this:

         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  |  NLPID  0xCC  |
         +-------------------------------+
         |          IP Datagram          |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

Unfortunately (or maybe fortunately), the mtu is undefined except that the
maximum frame size must be greater or equal to 262.

Frame relay may become important if anyone ever gets around to offering the
service.  For point-to-point links, which are the most common for ip today,
the main advantage of frame relay is that you don't need a state machine to
implement it.  The disadvantage is that you have to configure everything
manually, whereas with ppp you only need to configure one end manually.

 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Robert L Ullma » Sun, 10 Jan 1993 06:37:24


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
--

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 colima??on qui s'amor??ait dans l'arri?re-salle. ... Arriv? derri?re le
comptoir, il repousa le gar??on d'un geste n?gligent de la main, saisit
une bouteille de vin blanc, un verre, m?langea au vin de l'eau min?rale et,
la t?te renvers?e en arri?re, se gargarisa.  -- Simenon

 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Jim Re » Sun, 10 Jan 1993 08:33:16



  Ah, there are 3 (FR, PPP, X.25); and only X.25 is full-standard
  in both Internet and ISO/CCITT...
  One of the reasons you don't hear too much about X.25 is that it is _done_,

Actually, the reason you don't hear much about it is that running ip over
x.25 is too horrible to contemplate, even worse than ip over ppp.  It's
something people did back in the dark ages when x.25 was the only available
public data network in some countries, but it has no place in ip over isdn.

 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Jim Re » Sun, 10 Jan 1993 23:44:35



  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.

 
 
 

dp2.2 on Interactive V3.2 & ISDN

Post by Bob Sutterfie » Tue, 12 Jan 1993 04:43:04


(I keep telling myself that I should sit on my hands and stay out of
the fray, but a couple of comments warranted something in return...)


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

I might argue with that.  After 13 years of experience and three
rounds of standards (1980, 1984, and 1988), X.25 is starting to
mature.  But there are still buggy commercial X.25s out there, and
even some carriers with buggy implementations.  And as Jim pointed
out, X.25 is still confused as to its purpose and which layer it
should fill.

      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).

Thanks, but we've found X.25 to be much more complex than PPP, and
much harder to support in the field.  The biggest support problem is
X.25's unimaginable variety of options, and its primitive negotiation
methods.  It can be described in a sort of finite state machine, but
such a FSM must be inferred from the standards.  And that inferred FSM
is so complex, with so many special cases, as to be nearly
unimplementable.

Thus the wide variety of X.25 conformance testers.  In order to be
allowed to connect with a given nation's telephone system, an X.25
implementation must pass its own particular tests.  *All* those test
suites have serious bugs, so *all* X.25 implementations must have many
behaviors: one that comes as close as possible to meeting the CCITT
specs, and another for each network to which it wishes to connect - to
accomodate the bugs in that network's preferred test suite.

PPP may have complexity you consider unnecessary, but it's far simpler
than X.25, and far easier to support.  Just as one crude measure:

% cat /mst/obj/x25/*.[chysl] | wc
   75974  272360 2036095
5.0u 4.3s 0:20 46% 0+192k 0+0io 365pf+0w
% cat /mst/obj/ppp/*.[chysl] | wc
   26545   83864  616641
%

There has been talk from time to time of making a PPP conformance
tester, but in actual practice it really hasn't been very necessary so
far.  PPP implementors test against each other at periodic bakeoffs,
where everyone benefits.

      (In fairness, PPP has come a long way; but they did push through
      to Internet Standard a version that didn't even have a properly
      working state machine;

PPP has gone through three revisions (RFCs 1134, 1171, and 1331), and
now has a fairly mature state machine.  Most users just plug it in and
it just runs.

X.25 has gone through three revisions (1980, 1984, and 1988) and still
lacks any explicit state machine for negotiating configuration
options.  Each of its many options must still be hand-configured for
every link.

      and they still don't understand some things about datalink that
      have been known and implemented in (e.g.) X.25 for 2 decades.
      PPP _may_ still get somewhere; but I wouldn't use it yet.)

The PPP community hasn't solved all the problems, but it's learning
fast.  It has indeed gotten somewhere, and lots of people are using it
to solve their real-world problems.

   And as you yourself pointed out, there are poor commercial
   implementations of x.25.

There are poor commercial implementations of everything, including
both X.25 and PPP.  Hopefully, they're all maturing, so that customers
have a good field of choices to best match the demands of their own
applications.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827

 
 
 

1. dp2.2 on Interactive V3.2 & ISDN

Dear ppp-ers,

I am following the comp.dcom.isdn and comp.protocols.ppp newsgroups for a
while now. It seems to me that some people do actually use ISDN instead of
a common phone line + modems.

Could someone tell me how a  working configuration with ISDN looks like
(ISDN+TA+modem or ISDN-card plugged in a PC?). Personally, I would like to
use dp2.2, for its automatic dialup facilities and breakdown in
idle times.

In the first case (ISDN+TA+modem), it is probably rather easy to
configure dp2.2 to work with ISDN (just has to treat it as a modem?).

In the second case (ISDN card in PC), it seems to
me that there are parts missing in the dp daemon (to make a call via
the ISDN card).

Can anyone comment on this? Is it feasible to expand the amount of
keywords in the configuration file for dp (and build the knowledge to make
calls through the ISDN card into the dp daemon)?

Is their anybody using dp2.2 on an PC with Interactive UNIX V3.2?
Thanks/Gratien
--
  _______               Gratien D'haese    Switching Systems Division  se121
  \     /Alcatel                          F. Wellesplein 1, B-2018 Antwerpen


2. no word wrap

3. Lantastic v4.01/WFW v3.11 & Win NT v3.51 WS

4. Fatter Agnus

5. NT 4.0 & ISDN interactive login?

6. BEST Ethernet Controller IC

7. SNMPv2 & v3 Authentication with MRTG & HPOV

8. v3.2/v3.2bis/v4.2/v4.2bis modem sought

9. Telix v3.21 and C-Kermit v3.13

10. Netware V3.2 (V3.12 + Enh Pack) access by Apple Macs?

11. FS: Cisco Interactive Mentor: Lan Switching & Experts Labs IP Routing