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:
