Any device compatible with an Ascend cannot support payload (data) compression unless it uses the STAC algorithm. Also, unless otherwise noted, bearer channels cannot be aggregated. According to Marco Hyman, Ascend supports RFC1717 (the multilink PPP standards track), as well as its own extensions for better bandwidth control, which are being offered to the industry as a whole -- at no fee. If the Ascend MPP extensions are not available, the Ascend will drop back to MP. Like most new "standards," vendors are still working out their implementation details.
What about BONDING?
Curtis Sanford had this to say about BONDING:
> BONDING (Bandwidth ON Demand INteroperability Group) is a protocol for > CIRCUIT-SWITCHED aggregation of B-channels to form a synchronous channel > at the aggregate bitrate. It is available from the DCE serial ports on > the main MAX chassis, or from our MX-SL-2PMHP or our MX-SL-6PMHP slot > cards. These V.35/RS449/X.21 serial ports are generally connected to an > external bridge/router, mux, or videoconferencing terminal. The MAX on > these ports is acting as an IMUX'ing TA. > > When you make a remote LAN connection to the MAX, you are using a > different set of protocols, based on PPP. These aggregate at the packet > level, rather than the bit level, and we call that Multilink PPP (MPP), > and are strictly speaking not BONDING. "Bonding" has been generally > (mis)used to describe any channel aggregation, but BONDING is a specific > protocol. > > To support BONDING on the serial ports of your MAX, you have to buy an > additional software option such as MX-SO-NX or a package such as > MX-SP-VIDEO or MX-SP-DATA. But note that the latter of these packages > only supports Ascend Inverse Multiplexing (AIM), which is the native IMUX > protocol between Ascend products and much more functional than BONDING. > BONDING is supported in our products for compatibility with other > manufacturer's IMUX products. The other packages and options listed > include both AIM and BONDING.
What about V.120?
As of Ascend software rev 4.5, Ascend supports the V.120 asynchronous rate-adaption protocol, which should allow a larger number of terminal adapters without synchronous modes to communicate via asynch PPP.
I have successfully called a Cisco 2503 from an Ascend MAX and Pipeline 50, and dialed a MAX from the 2503. Data compression is not supported; I haven't tested multiple B channels. Attempts to use unnumbered BRI ports on the C2503 had "interesting" (read: frustrating) results.
The Cisco was running IOS 10.2(5), using ppp encapsulation and no ppp authentication (it will still authenticate CHAP and PAP requests from a remote MAX or P-50, but incoming calls will go unchallenged). When authentication is turned on on the Cisco, the PPP negotiation phase fails. It appears (to me) that this is caused by a difference in the way the two company's interpret the RFCs with respect to the proper way to authenticate calls.
Kevin Smith described a way to connect an Ascend to a Cisco without having to configure an unnumbered interface on the Cisco (which some networkers are loath to do):
> In reality, all that needs to happen is that the right routes > get put into the routing table...that can hapen in the way > documented, if the IP addresses are all available to you.... > otherwise, you can add routes using the static routes menus, > connection profiles....an alternative option is: > > > XYZ-net ----- [cisco] ---------- [Ascend] ----- My-net > ^ ^ ^ ^ > A B C D > > XYZ-net is my *desired* destination > A is a secret held by my ISP > B is the WAN IP address they shared with me > C is an IP address I *pretend* to be assigned to my > WAN interface > D is my ethernet IP address. > > Add a connection profile called [XYZ-net], with LAN IP address > set to (B) - yes the WAN address. Set the netmask to whatever it > is (OR /32 if you don't know/care). Then add a static route to > XYZ-net (see - we don't need to know (A)), where the gateway > is set to (B). > > The cisco will have a route pointing at "my-net" via address (C) > ......they don't need to know (D).[discussion of the authentication problem follows, from the Ascend and Cisco users' mailing lists. -ddl]
Keith Stone writes:
> The MAX returns a REJECT to the Cisco's request for CHAP during > the PPP initial link establishment phase, and so the authentication > phase where the two peers will swap names and passwords is never > reached. As far as I can tell this makes it impossible for the > Cisco to ever let the MAX know who it is, and so two way > authentication is not possible. I have tried this with 4.4 > and 4.4Ap12.Chris Chaundy laments:
> The proverbial rock and hard place... I guess the issues are > (1) why won't/can't the Ascend respond to the cisco CHAP request, > (2) why can't the cisco be set for one-way authentication (the > documentation implies that only one-way authenication is done). > > This becomes an issue when you have BRI interface where you want > to call on one channel and be called on the other - you can only > have one CHAP setting for both channels (of course, Ascend suffer > from similar problems in that you can only use one kind of > authentication for all ISDN channels).[Note that in rev 4.4+ code, the MAX/P400 can be set to authenticate incoming calls using PAP, CHAP, or either one -- whichever is used by the remote unit that's calling. Most recently (as of 4.4B) caller ID/ANI is supported too. -ddl]
Marco Hyman writes in response:
> An explanation of (1): > * It is "bad" to have one secret shared by all dial in users. > You may disagree with this statement. > * In order to look up the secret for a dial-in user I have to know > who he is. I don't who he is until he authenticates himself to me. > * PPP is peer-to-peer. I can't (or at least shouldn't) wait for the > caller to identify himself before picking the proper password for > PAP/CHAP negotiation. > > The above items lead me to believe that it is best to not do two-way > authentication on dial-in lines. This also gets around the inherent > security hole in PPP negotiation: > > There are two communiting units A and B. C pretends to be B and > calls A, requesting PAP. A sends C the password it uses when > talking to B. C now pretends to be A and calls B, using the > password it got from A in the first step. > > The Pipeline/Max is typically configured to require that dial-in > users authenticate themselve. The Pipeline/Max will refuse requests > to authenticate themselves to dial-in users. After all, how often > do you demand that the person you just called identify themselves > to you :-) > > I'll let one of the Cisco people answer (2).
The Datafire can dial an Ascend unit, but there have been problems reported with PAP/CHAP authentication. Specifically: a bug in the DOS/Windows Datafire drivers that always set the password to lower case; Win-NT drivers are more reliable. Even so, if the WinNT driver tries to negotiate a CHAP authentication algorithm different from the MD5 routine Ascend uses, negotiation may fail (this bug was fixed in Ascend software rev 4.5). In addition, Microsoft's drivers prevents Digi products from authenticating incoming calls.
Ken Germann reported that:
> The DOS Client PPP drivers for this board have been fixed and are > able to connect to an Ascend P50 with CHAP authentication enabled. > The upper and lower case issue in the user and password fields have > been fixed as well. > > ftp.digibd.com:/drivers/beta/isdn/dosclient/dc1321.EXE is the drivers.Here's an extensive set of instructions from Ken, on configuring a PC with a Digiboard and PPP for proper connection to an Ascend:
> There have been enough requests to warrant this: > > Quick Start PPP guide for setting up connections to the Ascend: > > ** THIS WILL NOT WORK CORRECTLY WITHOUT THE 1.3.2.1 DOS Client > beta drivers ** > > 1> At the C prompt, type 'cd \pc_imac'. > > 2> For an NDIS PPP type > 'ldndis datafire ppp' > > or > > For Netware ODI > 'ldodi datafire ppp' > > 3> You should see a '4 4 0' appear in the right hand side of > your screen within 30-60 seconds. If you don't see this > status, get faxback document #4020 at 612-943-0573. > > 4> pcp > > 5> Type at the pcp > prompt > > copy profile default ascend > > 5> Type at the pcp > prompt > > set profile ascend /user=Also see section on Windows NT below./pass=pass /auth=none > /fall=no /num=1 /address= > > 6> At the pcp > prompt > > save profile ascend > > 7> At the pcp > prompt > > conn ascend > > The connection with a single B channel should go active in a > few seconds. > > 8> Change the ldndis.bat or ldodi.bat file to do a 'conn ascend'. > This will allow you to do a 'call \pc_imac\ld .bat' > from your autoexec.bat file to setup the connection at the > time your PC is coming up. > > Note: > > WinISDN drivers are being worked on. They should be available > by mid-July to early August. These drivers will work with > Windows for Workgroups and Win 95. > > -------- Driver info ------ > > Driver information follows: > > ISDN Beta Drivers > -------------------------------------------------------------------- > > Notes: Start your FTP clients in binary mode. From a unix or > like > host with a command line for ftp you can enter do a > 'ftp -i -n ftp.digibd.com' or 'ftp -i -n 199.86.0.193'. > > Recommend using Ymodem or Zmodem for Download protocol. > Xmodem and Kermit are going to be slower protocol for > downloading files. > > OS: WFWG 3.11 (Windows for Workgroups) > Digi: Datafire - PC IMAC > > BBS Login: iwfwbeta > Password: wfw100 > File(s): wfw100.exe > > FTP Login: anonymous Password: email address > Directory: cd /drivers/beta/isdn/wfw > File(s): wfw100.exe > -------------------------------------------------------- > OS: Novell > Digi: PC IMAC - PC IMAC/X > > BBS Login: nw41beta > Password: nw130e > File(s): nw130e1.exe & nw130e2.exe > > FTP Login: anonymous Password: email address > Directory: cd /drivers/beta/isdn/nw > File(s): nw130e1.exe & nw130e2.exe > -------------------------------------------------------- > OS: DOS Client beta released 5/30/95 > Digi: Datafire - PC IMAC > > BBS Login: dclient > Password: dc1321 > File(s): dc1321.exe > > FTP Login: anonymous Password: email address > Directory: cd /drivers/beta/isdn/dosclient > File(s): dc1321.exe > > Relnotes: Chap Authenticator fixed, some size reduction done, > mixed case login/password fixed. > -------------------------------------------------------- > > OS: Win NT 3.5 > Digi: Datafire - PC IMAC - PC IMAC/4 > > BBS Login: int35bta > Password: nt130b9 > File(s): nt130b9.exe > > FTP Login: anonymous Password: email address > Directory: cd /drivers/beta/wnt35b9/nt130b9.exe > File(s): nt130b9.exe
Digi is actively soliciting Ascend<->Digi problem reports, so they seem interested in solving incompatibility problems. Contact keng@digibd.com.
Combinet EVERYWHERE 2000 series software 3.0.1 and later supports both PPP and MP, as well as their proprietary protocol. Thus, they should be interoperable without using special Combinet settings.
[Combinet 150]
Gandalf makes remote ISDN routers and bridges, the LANLine 5240i
and 5242i, which now (as of August 1995) support PPP and MP, and
are therefore compatible. I have no personal experience in testing
interoperability between the two (yet).
Concerning their central-office hub, an engineer at Gandalf
told me the following:
Note that Gandalf units will include STAC compression as an optional
standard for when their proprietary compression algorithm cannot
be employed. (This may be available now, August 1995; I'm not sure.)
Gandalf also has a 5250 line of routers, with which I have no
experience.
Click here to go to the
Gandalf web page.
Zbigniew J. Tyrlik writes:
See section on Windows NT below.
Bob Atkins writes:
Laurence V. Marks reports
that the WaveRunner card with rel.2.2 software can dial Ascend
units, using the WinISDN interface. I don't know whether that
applies to the ISA card, the PC-card, or both.
[It's been reported that this PC-card T.A. works, but I have no
details on it myself. -d.d.]
Dror Matalon wrote:
Several users have written in to attest to success in calling
Ascend units from BitSURFRs.
Robert Sanders
gave advice about doing so using Trumpet Winsock:
[It's been reported that this T.A. works, but I have no
details on it myself. -d.d.]
Jan Bottorff uncovered some
details on reported compatibility problems between Ascend's
and Windows NT's PPP implementations. Following is a semi-long
account:
Jacques Vidrine reports that
Microsoft will be including support for Multipoint PPP [MP] in the next
revision of Windows NT, due late 1995 or early 1996, and possibly in a
service package update sometime before then.
SET DEFAULTS
SET 1 NU = dial number
SET 1 TI = 120
SET IP y.y.y.y
SET SU 255.255.255.0
SET PAS SY xxxxxx
SET PAS CL xxxxxx
> The Xpressway 3.0 release does work with the Ascend. Indeed for a
> while it worked with two B channels with ascend. However when ascend
> released the newer software it stopped working with two B channels.
> I cannot give you the exact details as our PPP guru is on vacation.
>
> The Gandalf Xpressway supports the MP protocol extensions. The main
> issue I think is when will we see a standardized compression that
> can be used used to improve throughput. Having just one/two B
> channels without compression really isn't that impressive. I do
> hope this gets resolved soon.
> I got 3Com Impact (previously Access Works) to work with Ascend;
> using software rev 1.5 on 3Com, and connecting from Win3.1 unit,
> using Trumpet DLL. PAP was enabled on both ends. I was unable to
> get it working with NT machine.
> Yes, I am using the SunLinkISDN v1.0.2 with a SPARC LX and it works
> just fine.
>
> The PPP package that is shipped with Solaris does not support an ISDN link.
> You will need a copy of SunLinkISDN v1.0.2. As regards to successes or
> failures overall I found the SunLinkISDN package a bit challenging
> without any documentation, however the configuration files are fairly
> well commented. No failures to speak of, but then again ISDN WAN
> is my business :)
> The Ascend will drop the line after 5-15 Secs of inactivity
> when connected to this device. Going into debug mode and typing
> "noidle" will make this behavior go away and the line gets timed
> out after the number of minutes we specify in the RADIUS entry.
> This works quite nicely except that the 400 reverts to the
> original behavior on its own and we need to go through the process
> of going into debug mode and typing noidle again.
> We found out the "noidle" work around from Ascend support who
> told us that the Ascend sends a query to the other device to see
> if it's there and the Securelink doesn't respond which is why the
> 400 times out. The noidle is a [short-term] workaround for that.
> Trumpet doesn't bridge. Use routing on, bridging off. Turn on proxy
> arp if you're using an IP address from the same subnet the P50's
> ethernet interface is on.
>
> There are some other important parameters, most of which have been
> mentioned here and on comp.dcom.isdn. Turn link compression off in
> the P50, use PAP, set the BitSURFR's protocol to PPPC, etc.
>
> I've used Trumpet with both a P50 and a MAX with excellent results.
And Turnando Fuad noted that
"We had to do manual login in Trumpet instead of the script and
hit the ESC key once you make the connection and PAP will kick in."
[from email to support@ascend.com]
> My ISP is using P50's on each BRI line and I was using Microsoft
> Windows NT 3.5 connected to an ISDN Terminal Adapter (Quick Access
> Remote). They were calling my TA with NT 3.5 doing the PPP protocol.
>
> Using the NT SMS network sniffer, I have packet traces that seem to
> indicate the P50 ack's authentication protocol it does not support.
> The trace goes like this:
>
> A few LCP packets are exchanged and rejected. NT eventually sends
> one that requests CHAP authentication with an encryption algorithm
> field of 0x80. The PPP authentication RFC does not say what encryption
> method 0x80 is, but does say that 0x5 is MD5. The Pipeline 50 send an
> ack, apparently accepting this configuration. My belief is algorithm
> 0x80 is DES. The NT Resource Kit seems to say NT will use MD5 or DES
> when dialing out, but allways uses DES for dial-in calls. NT then
> starts sending the challenge packets. The response comes back, and
> is not accepted. NT actually logs an error, probably because the
> reply packets are not even the correct length. NT then tries 8 more
> times and disconnects. I believe the response packets are encrypted with
> MD5, not DES as was negotiated. I believe this because the length of the
> response packets has the correct 16 byte (for MD5) size for some data
> fields. NT is quite willing to negotiate down to PAP authentication if
> the remote end will not do CHAP. The Pipeline 50 says it's willing to
> do CHAP w/DES, so things never authenticate correctly.
The above problem was fixed as of Ascend rev. 4.5.