On Sun, Jul 04, 2010, Michael Sokolov wrote:
OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router thread.
It's ok. I'll trade you Russian for Australian currency. I don't know which is going to be better in the long run.
With non-Ethernet WAN interfaces one really needs an extra layer of highly configurable software functionality sandwiched in between the hardware interface unit and the ifconfig layer. The physical hardware interface is a synchronous serial bit stream processor that sends and receives either HDLC frames or ATM cells, and that is where the
Hey, sounds like FreeBSD's NetGraph!
hardware-dictated part ends. Let's take the case of HDLC as it's more pleasant than ATM: in the case of HDLC the software layer between the HDLC controller and the ifconfig layer needs to do the following:
* Let the user choose the encapsulation, and there are many choices: Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR (RFC 1973), ATM FUNI, etc.
ng_<encapsulation_module>
* If it's a Frame Relay encapsulation, let the user configure DLCIs. Oh, and there can be more than one, hence there may be multiple ifconfig-able entities on the same FR interface.
ng_<some other module>
* RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated and true routed circuits; our software layer should support both, as as well as the possibility of mixing the two on different FR interfaces or different DLCIs on the same interface. These two modes need to look different to the ifconfig layer: if it's a bridged encapsulation, ifconfig needs to see a virtual Ethernet interface ("virteth0" or "macwan0"); if it's a true routed encapsulation, ifconfig needs to see a MAC-less and ARP-less point-to-point interface like "ipwan0".
ng_bridge, IIRC
* Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) if the underlying hardware is capable of both (like Freescale MPC862 and MPC866). Let's provide a user to switch between the two with a simple software command, and let's provide as much commonality as possible between the two configurations: let's support all RFC 1483 encapsulations on HDLC via FUNI, but make the configuration commands look just like ATM. Let's also support FRF.5 by allowing one to take an ATM PVC and treat its payload as a virtual HDLC interface, with possibly many FR DLCIs inside.
I think there's ng_<atm> stuff; I could be wrong. There should be functional ATM code in FreeBSD and if so, I'd be surprised to find it isn't linked into netgraph.
I would love to be corrected on this, but I am not aware of anyone having implemented all of the above for Linux (or for any BSD variant) in a clean and generalized manner. Instead what we see is that each vendor of a PCI card for some non-Ethernet WAN interface has their own ad hoc solution which typically comes nowhere close to what I've outlined above in terms of generality and flexibility.
FreeBSD netgraph. It's clean, it's generalised, it's just not very well documented.
Now here is something I'd like to build which will attempt to solve this mess. I'd like to build a modular WAN router based on the MPC866 chip from Freescale, former Motorola. MPC866 is a PowerPC with one very neat twist: it has 4 serial communication controller (SCC) cores on chip. Each SCC has a traditional 7-wire serial interface coming out of it (Rx data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell delineation for a raw bit stream and octet-by-octet cell delineation for use with a framer that provides octet boundaries.)
Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn FreeBSD into it somehow, help tidy up the code to do whateveer you need and start leveraging the very powerful network stack FreeBSD has. FreeBSD-head has support for multiple routing tables which I believe you can just dump netgraph interface nodes into to support VRFs. I'm peripehrally doing something similar as a prototype using FreeBSD/MIPS on ubiquiti hardware - but I'm mostly squeezing my squid fork onto it and making it work "right". :) Adrian
My modular router would be rather unique in that the interface to the pluggable WAN modules would not be PCI or anything of that sort, instead it would be the 7-wire serial interface coming from an MPC866 SCC, and there would be 4 possible daughtercard slots corresponding to the 4 SCCs.
When the interface for pluggable WAN modules is something like PCI, the HDLC or ATM (including SAR) core has to be reimplemented anew by everyone who wants to build a new WAN module for a different flavor of Layer 1 physical interface, and I find it wasteful. The proliferation of such reinvented-wheel HDLC/ATM reimplementations is precisely the reason why there is no universally-accepted standardized framework for non-Ethernet WAN interfaces in Linux or *BSD.
But if the cores implementing HDLC and ATM SAR reside inside the CPU chip like they do with MPC86x processors, we can have ONE well-written generic driver for these cores, and it will work exactly the same way and provide exactly the same array of configurable Layer 2 options to the user regardless of which Layer 1 interface is used: we can build daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized circuitry on each of these daughtercards will only concern itself with Layer 1, not with HDLC or ATM SAR.
I would greatly appreciate any leads/ideas/suggestions as to who might possibly be interested in funding such a project. :-)
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -