Date: Mon, 27 May 1996 00:38:09 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Michael Hancock <michaelh@cet.co.jp> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, FreeBSD hackers list <FreeBSD-hackers@FreeBSD.ORG> Subject: Re: all this talk about routers and all... Message-ID: <199605270438.AAA11508@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 27 May 1996 11:41:52 %2B0900." <Pine.SV4.3.93.960527111440.23778C-100000@parkplace.cet.co.jp> References: <Pine.SV4.3.93.960527111440.23778C-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> Having said that, I don't want people to get the impression that this is a > FreeBSD vs. Ascend religious war. This about making an ISDN solution with > FreeBSD. > > Ascend just naturally comes up as a benchmark but I don't think > its necessary for the advocates of Ascend to defend it unless there is > blatant misinformation posted in this mailing list. The major point not really discussed if you're making a comparison is the fact that you can install V.34 digital modems in an Ascend solution, and use the same ISDN PRI facility to service both callers with V.32/V.32bis/V.34 modems, as well as callers with ISDN TAs or doing synchronous PPP on an 64 kb/s B channel. Obviously, the advantages of handling modem calls is that you can have one larger rotary, for both types of callers, rather than two different ones and having to worry about adding capacity to each one individually. If modem calls are not an issue, clearly you can ignore all of this. > I'm interested in seeing something work with FreeBSD because Net/3 is > world class code, the radix trie stuff makes routing very efficient. > Maybe some of van Jacobson's post Net/3 research on large contiguous > buffers will find it's way into BSD when the cost of RAM becomes less of > an issue. I think the real software issue isn't really the IP forwarding function which is done pretty well well in FreeBSD. It's likely not "complicated" routing, as you can cobble stuff together using gated. This code is pretty mature in the FreeBSD environment. The difficultly faced is building a ISDN signalling stack to run on the D channel and talk to the switch. This is where a bunch of emperical knowledge and experence has made an Ascend platform a good choice in many environments. You'll need a Q.920/Q.921 LAPD level-2 protocol to run on the 64kb/s D channel to carry frame back and forth between the ISDN terminal and the switch. Certainly the HDLC implementation would be done in the hardware interface, but there are also some higher-level X.25-like transport stuff going on in here, too. Then you'll need a Q.930/Q.931 level-3 protocol stack for actually communicating call processing events between the switch and the ISDN terminal. I believe this is where you'll find a variety of different, switch-specific implementation differences to deal with. I think this is where the real challange is. Once you've managed to get the ISDN call running, you can hack it into your existing PPP stack without huge differences and away you go. That why I was interested in what sort of software development kits might be available, and the status of the drivers. My past experience has been that there are no real freely available ISDN signalling stacks available, so either you roll your own from scratch or license it from someone else. It would be very cool to have an ISDN signalling stack in FreeBSD. Done there right way, you could use it to drive a bunch of ISDN BRI interfaces (looking like a switch), and build yourself a PBX using ISDN voice terminals, er, "phones" rather than the various proprietary digital phone sets you get from NT, etc. Louis Mamakos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605270438.AAA11508>